Kirill Sizov created IGNITE-20347:
--------------------------------------
Summary: 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
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.
If the provided transaction id does not match the write intent the row has, 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)
