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

Vyacheslav Koptilin updated IGNITE-20395:
-----------------------------------------
    Description: 
If a transaction was committed/aborted, but for any reason the cleanup 
operation was not performed on a node, the write intent entries would still be 
present in the storage. 
For example, the primary node crashed before executing the cleanup. In this 
case the storage will still have write intents even if the transaction is 
finished.

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 (happens on primary only), it also 
performs write intent resolution. But any following change of the rows having 
write intents will result in a storage exception because the storage doesn't 
support more than one write intent per row.

IGNITE-20041 added a way to trigger async write intent cleanup on the node that 
executes write intent resolution. But RW transaction does not wait the 
completion of the cleanup.

*Definition of done:*
If an RW transaction performs write intent resolution for a row and this is a 
modifying action (not GET), we should synchronously cleanup the write intent 
before proceeding with executing UpdateCommand.

*Implementation details*

We can either call cleanup directly (like in {{processTxCleanupAction}} or wait 
for the cleanup future (the result of async cleanup execution method) to finish

  was:
If a transaction was committed/aborted, but for any reason the cleanup 
operation was not performed on a node, the write intent entries would still be 
present in the storage. 
For example, the primary node crashed before executing the cleanup. In this 
case the storage will still have write intents even if the transaction is 
finished.

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 (happens on primary only), it also 
performs write intent resolution. But any following change of the rows having 
write intents will result in a storage exception because the storage doesn't 
support more than one write intent per row.

IGNITE-20041 added a way to trigger async write intent cleanup on the node that 
executes write intent resolution. But RW transaction does not wait the 
completion of the cleanup.

*Definition of done:*
  If an RW transaction performs write intent resolution for a row and this is a 
modifying action (not GET), we should synchronously cleanup the write intent 
before proceeding with executing UpdateCommand.

*Implementation details*

We can either call cleanup directly (like in {{processTxCleanupAction}} or wait 
for the cleanup future (the result of async cleanup execution method) to finish.


> Clean up write intents for RW transaction on primary
> ----------------------------------------------------
>
>                 Key: IGNITE-20395
>                 URL: https://issues.apache.org/jira/browse/IGNITE-20395
>             Project: Ignite
>          Issue Type: Task
>            Reporter:  Kirill Sizov
>            Assignee:  Kirill Sizov
>            Priority: Major
>              Labels: ignite-3
>          Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> If a transaction was committed/aborted, but for any reason the cleanup 
> operation was not performed on a node, the write intent entries would still 
> be present in the storage. 
> For example, the primary node crashed before executing the cleanup. In this 
> case the storage will still have write intents even if the transaction is 
> finished.
> 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 (happens on primary only), it also 
> performs write intent resolution. But any following change of the rows having 
> write intents will result in a storage exception because the storage doesn't 
> support more than one write intent per row.
> IGNITE-20041 added a way to trigger async write intent cleanup on the node 
> that executes write intent resolution. But RW transaction does not wait the 
> completion of the cleanup.
> *Definition of done:*
> If an RW transaction performs write intent resolution for a row and this is a 
> modifying action (not GET), we should synchronously cleanup the write intent 
> before proceeding with executing UpdateCommand.
> *Implementation details*
> We can either call cleanup directly (like in {{processTxCleanupAction}} or 
> wait for the cleanup future (the result of async cleanup execution method) to 
> finish



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

Reply via email to