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

Alexander Lapin updated IGNITE-20445:
-------------------------------------
    Reviewer: Vladislav Pyatkov  (was: Alexander Lapin)

> 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
>            Assignee:  Kirill Sizov
>            Priority: Major
>              Labels: ignite-3
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> 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)

Reply via email to