[jira] [Updated] (IGNITE-21761) Within commitPartition mark txnState with cleanup replication finished timestamp

["Alexander Lapin (Jira)" <ji...@apache.org>]

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

Alexander Lapin updated IGNITE-21761:
-------------------------------------
    Summary: Within commitPartition mark txnState with cleanup replication finished timestamp  (was: Within commitPartition mark Mark txnState with a timestamp on cleanup replication finished)

> Within commitPartition mark txnState with cleanup replication finished timestamp
> --------------------------------------------------------------------------------
>
>                 Key: IGNITE-21761
>                 URL: https://issues.apache.org/jira/browse/IGNITE-21761
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Alexander Lapin
>            Priority: Major
>              Labels: ignite-3
>
> h3. Motivation
> Volatile txn state removal is implemented in IGNITE-21759 Worth mentioning that having volatile txnState is mainly an optimization just because it might be lost on node restart.
> This ticket is about marking txnState persistent state as ready for removal. Basically it is ready for removal when the state is either COMMITED or ABORTED and cleanup is fully replicated over majority of all enlisted partitions. There are some nuances related to txn recovery case that will be covered in another jiras.
> h3. Definition of Done
>  * In a durable manner (meaning retry on failure) await cleanup replication over majority of all enlisted partitions. 
>  * On cleanup done, compute txnState in txnStateVolatileMap with System.currentTimeMillis(). Pay attention that depending on whether given txnState was already removed by TxnResourseCleanupTask or not, it's either an adjusting of an exiting entry in txnStateVolatileMap with timestamp or writing a brand new record. In latter case another iteration of TxnStateCleanupTask will remove newly created entry. Besides that if the volatile state was removed it won't be possible to restore all the meta, which is fine, because all we need is txnId, txnState and System.currentTimeMillies as cleanupReplicationFinished timestamp.
>  * There will be another Jira that will consider such timestamps and remove corresponding states from txnStatePersistentStorage. For know it's out of scope.
>  * There will be another task that will redo the cleanup on node startup in order to restore (or formally re-evaluate) the cleanup replication finished timestamp. For know it's out of scope.



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