[
https://issues.apache.org/jira/browse/IGNITE-21761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-21761:
-------------------------------------
Description:
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.
> Within commitPartition mark Mark txnState with a timestamp on cleanup
> replication finished
> ------------------------------------------------------------------------------------------
>
> 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)
