[
https://issues.apache.org/jira/browse/IGNITE-20347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17954082#comment-17954082
]
Roman Puchkovskiy commented on IGNITE-20347:
--------------------------------------------
The patch looks good to me
> Add transaction id to commitWrite and abortWrite methods of Storage
> -------------------------------------------------------------------
>
> Key: IGNITE-20347
> URL: https://issues.apache.org/jira/browse/IGNITE-20347
> Project: Ignite
> Issue Type: Task
> Reporter: Kirill Sizov
> Assignee: Kirill Tkalenko
> Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently both {{commitWrite}} and {{abortWrite}} from {{MvPartitionStorage}}
> are expected to be called from the transaction that made the changes.
>
> This is how they look like:
> {code}
> /**
> * Aborts a pending update of the ongoing uncommitted transaction.
> Invoked during rollback.
> *
> * @param rowId Row id.
> * @return Previous uncommitted row version associated with the row id.
> * @throws StorageException If failed to write data to the storage.
> */
> @Nullable BinaryRow abortWrite(RowId rowId) throws StorageException;
> {code}
> and
> {code}
> /**
> * Commits a pending update of the ongoing transaction. Invoked during
> commit. Committed value will be versioned by the given timestamp.
> *
> * @param rowId Row id.
> * @param timestamp Timestamp to associate with committed value.
> * @throws StorageException If failed to write data to the storage.
> */
> void commitWrite(RowId rowId, HybridTimestamp timestamp) throws
> StorageException;
> {code}
> If any of these methods are to be called asynchronously, they will need
> special handling to avoid commiting write intents from a mismatching
> transaction.
> Imaging the case
> - Transaction txrw1 creates a write intent for row1. txrw1 is committed but
> write intents are not finalized.
> - Both new transactions txrw2 and txro3 see write intent for the same row,
> resolve it and want to do a cleanup in the background.
> - the background task from txrw2 runs first, commits that write intent. Then
> txrw2 adds its own write intent for row1
> - now the background task from txro3 runs. Should it silently commit the same
> row, it would write a write intent from a running transaction txrw2, not from
> the committed txrw1.
> Right now we have to do another data read prior to committing to avoid the
> described case.
> *Definition of Done*
> Both commitWrite and abortWrite should be extended with a new parameter
> transaction id ({{UUID txId}}).
> If the provided transaction id does not match the one from the row's write
> intent, the commit/abort operation should not run.
> *Implementation details*
> There are two options what to do if the passed transaction id does not match
> the one from the write intent:
> - either throw TxIdMismatchException
> - or return false from the method indicating that it did nothing.
> The decision to be made while working on this task.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
