[
https://issues.apache.org/jira/browse/IGNITE-21761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov 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 txn 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,
including pre-cleanup within primary replica. 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 along with corresponding pre-cleanup
within primary replica.
* On cleanup done, compute txnState in txnStateVolatileMap by setting
txnState.cleanupCompletionTimestamp to System.currentTimeMillis(). Pay
attention that depending on whether given txnState was already removed by
TxnResourseVacuumTask 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 now 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 now it's out of scope.
was:
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 txn 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,
including pre-cleanup within primary replica. 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 along with corresponding pre-cleanup
within primary replica.
* On cleanup done, compute txnState in txnStateVolatileMap by setting
txnState.cleanupCompletionTimestamp to System.currentTimeMillis(). Pay
attention that depending on whether given txnState was already removed by
TxnResourseVacoomTask 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 now 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 now it's out of scope.
> 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
> Assignee: Kirill Sizov
> 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 txn 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, including pre-cleanup within primary replica. 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 along with corresponding pre-cleanup
> within primary replica.
> * On cleanup done, compute txnState in txnStateVolatileMap by setting
> txnState.cleanupCompletionTimestamp to System.currentTimeMillis(). Pay
> attention that depending on whether given txnState was already removed by
> TxnResourseVacuumTask 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 now 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 now it's out of scope.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
