[
https://issues.apache.org/jira/browse/IGNITE-20445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov updated IGNITE-20445:
-----------------------------------
Description:
If a transaction was committed/aborted and for any reason the cleanup operation
was not performed on a node, the write intent entries would still be present in
the storage.
When an RO transaction sees write intents, no matter on primary or on any other
node, it performs write intent resolution and returns the correct result.
When an RW transaction sees write intents, we can get an exception.
_Imagine the case where a finished transaction left its write intents in the
storage of all nodes A, B and C. A is primary._
_An RO transaction is executed on the primary A, it kicks off an async cleanup
(IGNITE-20041)._
_The cleanup is a local task (not distributed to the replication group), thus
only the A's storage is cleaned. B and C storages still contain the same write
intent._
_Now an RW transaction starts. It sees no write intents on A, executes its
action and the action is replicated to B and C. Execution of this task on B and
C will result in a storage exception since it's not allowed to have more than
one write intent per row._
*Definition of Done*
The nodes of the replication group should perform cleanup of their storages
when they receive an UpdateCommand, before adding new write intents.
*Implementation details*
We can extend the update command with the timestamp of the latest commit on
primary.
If the nodes of the replication group see a write intent in their storage, they
will:
* +commit+ the write intent if the UpdateCommand`s latestCommitTimestamp is
greater than the commit timestamp of latest committed entry.
* +abort+ the write intent if he UpdateCommand`s latestCommitTimestamp is
equal to the commit timestamp of latest committed entry.
was:
If a transaction was committed/aborted and for any reason the cleanup operation
was not performed on a node, the write intent entries would still be present in
the storage.
When an RO transaction sees write intents, no matter on primary or on any other
node, it performs write intent resolution and returns the correct result.
When an RW transaction sees write intents, we can get an exception.
_Imagine the case where a finished transaction left its write intents in the
storage of all nodes A, B and C. A is primary._
_An RO transaction is executed on the primary A, it kicks off an async cleanup
(IGNITE-20041)._
_The cleanup is a local task (not distributed to the replication group), thus
only the A's storage is cleaned. B and C storages still contain the same write
intent._
_Now an RW transaction starts. It sees no write intents on A, executes its
action and the action is replicated to B and C. Execution of this task on B and
C will result in a storage exception since it's not allowed to have more than
one write intent per row._
*Definition of Done*
The nodes of the replication group should perform cleanup of their storages
when they receive an UpdateCommand, before adding new write intents.
*Implementation details*
We can extend the update command with the timestamp of the latest commit on
primary.
If the nodes of the replication group see a write intent in their storage, they
will:
* +commit+ the write intent if the UpdateCommand`s latestCommitTimestamp is
greater than the commit timestamp of latest committed entry.
* abort the write intent if he UpdateCommand`s latestCommitTimestamp is equal
to the commit timestamp of latest committed entry.
> Clean up write intents for RW transaction on replication group nodes
> --------------------------------------------------------------------
>
> Key: IGNITE-20445
> URL: https://issues.apache.org/jira/browse/IGNITE-20445
> Project: Ignite
> Issue Type: Task
> Reporter: Kirill Sizov
> Priority: Major
> Labels: ignite-3
>
> If a transaction was committed/aborted and for any reason the cleanup
> operation was not performed on a node, the write intent entries would still
> be present in the storage.
> When an RO transaction sees write intents, no matter on primary or on any
> other node, it performs write intent resolution and returns the correct
> result.
> When an RW transaction sees write intents, we can get an exception.
> _Imagine the case where a finished transaction left its write intents in the
> storage of all nodes A, B and C. A is primary._
> _An RO transaction is executed on the primary A, it kicks off an async
> cleanup (IGNITE-20041)._
> _The cleanup is a local task (not distributed to the replication group), thus
> only the A's storage is cleaned. B and C storages still contain the same
> write intent._
> _Now an RW transaction starts. It sees no write intents on A, executes its
> action and the action is replicated to B and C. Execution of this task on B
> and C will result in a storage exception since it's not allowed to have more
> than one write intent per row._
> *Definition of Done*
> The nodes of the replication group should perform cleanup of their storages
> when they receive an UpdateCommand, before adding new write intents.
> *Implementation details*
> We can extend the update command with the timestamp of the latest commit on
> primary.
> If the nodes of the replication group see a write intent in their storage,
> they will:
> * +commit+ the write intent if the UpdateCommand`s latestCommitTimestamp is
> greater than the commit timestamp of latest committed entry.
> * +abort+ the write intent if he UpdateCommand`s latestCommitTimestamp is
> equal to the commit timestamp of latest committed entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
