[ 
https://issues.apache.org/jira/browse/IGNITE-21759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Lapin updated IGNITE-21759:
-------------------------------------
    Description: 
h3. Motivation

Within one of Txn cursros cleanup sub tickets cursor cleanup scheduler was 
introduced. Now it's turn to generalize it to handle txn resource cleanup task. 
Thus it's expected that two new entities will be introduced: 
TxnResourceCleanupTask and TxnResourceCleanupContext, the latter is expected to 
be node-local, volatile and be, probably, a part of a TxManager.

Few words about the logic inside TxnResourceCleanupTask that is expected to be 
implemented within given ticket (it'll be adjusted later on in other jiras):
 # CleanupTask evaluates txnStateCleanupWatermark as System.currentTimeMillis. 
There's no sense in using common clock and thus we may reduce the contention.
 # CleanupTask iterates over txnResourceCleanupContext.txnStatesToCleanup and 
if txnState.markForRemovalTimestamp + txnStateTTL (more details a bit later) >= 
txnStateCleanupWatermark:
 ## Removes given txnId from txnStateVolatileMap.
 ## Removes same txnId from txnResourceCleanupContext.txnStatesToCleanup.
 # CleanupTask scans txnStateVolatileMap and filters all finished (COMMITED or 
ABORTED) transactions. 
 # Depending on txnStateTTL cleanupTask either removes the finished entry from 
the txnStateVolatileMap (if txnStateTTL == 0) or populates the 
txnResourceCleanupContext.transactionsToCleanup map with txId -> 
txnStateCleanupWatermark semantically txnToCleanupDetectionTime. Such bypassing 
- immediate removal instead of common "mark -> nextTimerIteration -> remove" is 
useful for testing purposes.
 

txnStateTTL is a new cluster configuration property that defines the *minimum* 
lifetime of a transaction state in milliseconds. Real txnState lifetime will 
also depend on cleanupTimer intervals which of course not suitable for test 
purposes thus we should introduce manual ability to run TxnResourceCleanupTask 
immediately. At least we will use it within tests.
h3. Definition of Done
 * New configuration property txnStateTTL is introduced with default of 30_000 
milliseconds.
 * At least two new classes are introduced: TxnResourceCleanupTask and 
TxnResourceCleanupContext.
 * Cleanup scheduler is generalized and adjusted to run TxnResourceCleanupTask 
on every iteration.
 * TxnResourceCleanupTask is thread safe, and implemented according to the 
description in motivation section.
 * Special trigger txnResourceCleanup is introduced within TxManager.

> Prepare general txn cleanup logic: txnCleanupTask along with txnCleanupContext
> ------------------------------------------------------------------------------
>
>                 Key: IGNITE-21759
>                 URL: https://issues.apache.org/jira/browse/IGNITE-21759
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Alexander Lapin
>            Priority: Major
>
> h3. Motivation
> Within one of Txn cursros cleanup sub tickets cursor cleanup scheduler was 
> introduced. Now it's turn to generalize it to handle txn resource cleanup 
> task. Thus it's expected that two new entities will be introduced: 
> TxnResourceCleanupTask and TxnResourceCleanupContext, the latter is expected 
> to be node-local, volatile and be, probably, a part of a TxManager.
> Few words about the logic inside TxnResourceCleanupTask that is expected to 
> be implemented within given ticket (it'll be adjusted later on in other 
> jiras):
>  # CleanupTask evaluates txnStateCleanupWatermark as 
> System.currentTimeMillis. There's no sense in using common clock and thus we 
> may reduce the contention.
>  # CleanupTask iterates over txnResourceCleanupContext.txnStatesToCleanup and 
> if txnState.markForRemovalTimestamp + txnStateTTL (more details a bit later) 
> >= txnStateCleanupWatermark:
>  ## Removes given txnId from txnStateVolatileMap.
>  ## Removes same txnId from txnResourceCleanupContext.txnStatesToCleanup.
>  # CleanupTask scans txnStateVolatileMap and filters all finished (COMMITED 
> or ABORTED) transactions. 
>  # Depending on txnStateTTL cleanupTask either removes the finished entry 
> from the txnStateVolatileMap (if txnStateTTL == 0) or populates the 
> txnResourceCleanupContext.transactionsToCleanup map with txId -> 
> txnStateCleanupWatermark semantically txnToCleanupDetectionTime. Such 
> bypassing - immediate removal instead of common "mark -> nextTimerIteration 
> -> remove" is useful for testing purposes.
>  
> txnStateTTL is a new cluster configuration property that defines the 
> *minimum* lifetime of a transaction state in milliseconds. Real txnState 
> lifetime will also depend on cleanupTimer intervals which of course not 
> suitable for test purposes thus we should introduce manual ability to run 
> TxnResourceCleanupTask immediately. At least we will use it within tests.
> h3. Definition of Done
>  * New configuration property txnStateTTL is introduced with default of 
> 30_000 milliseconds.
>  * At least two new classes are introduced: TxnResourceCleanupTask and 
> TxnResourceCleanupContext.
>  * Cleanup scheduler is generalized and adjusted to run 
> TxnResourceCleanupTask on every iteration.
>  * TxnResourceCleanupTask is thread safe, and implemented according to the 
> description in motivation section.
>  * Special trigger txnResourceCleanup is introduced within TxManager.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to