[
https://issues.apache.org/jira/browse/IGNITE-17578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17578:
-------------------------------------
Labels: ignite-3 transaction transaction3_recovery (was: ignite-3
transaction3_rw)
> Transactions: async cleanup processing on tx commit
> ---------------------------------------------------
>
> Key: IGNITE-17578
> URL: https://issues.apache.org/jira/browse/IGNITE-17578
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: ignite-3, transaction, transaction3_recovery
>
> h3. Motivation
> Within RW transaction commit process, according to the tx design it's
> required to return the control to the outer logic right after
> # COMMITED/ABORTED txn state replication
> # Locks release.
> Follow-up cleanup process, that will apply or remove write intents, should be
> asynchronous. Currently, it's not true. It also worth to mention that
> currently, locks are released after write intent application. That should be
> inverted. Such enhancements mean that not only RO but also RW transactions
> may retrieve writeIntent and thus perform writeInentResolution - it's covered
> with separate ticket https://issues.apache.org/jira/browse/IGNITE-19570 that
> should be implemented prior to this one.
> h3. Definition of Done
> * Write intent application or removal should be implemented in an async
> format.
> * Write intent applicatoin and locks release process should be
> h3. Implementation Notes
> Generally it's only required to change some code in
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#processTxCleanupAction
> {code:java}
> return allOffFuturesExceptionIgnored(txUpdateFutures,
> request).thenCompose(v -> {
> TxCleanupCommand txCleanupCmd = MSG_FACTORY.txCleanupCommand()
> .txId(request.txId())
> .commit(request.commit())
> .commitTimestampLong(request.commitTimestampLong())
> .safeTimeLong(hybridClock.nowLong())
> .build();
> return raftClient
> .run(txCleanupCmd)
> .thenCompose(ignored ->
> allOffFuturesExceptionIgnored(txReadFutures, request)
> .thenRun(() -> releaseTxLocks(request.txId())));
> });
> } {code}
> * releaseTxLocks priour to sending txCleanupCmd.
> * send txCleanupCmd in async manner, meaning that processTxCleanupAction
> should return the result after locks are released.
> It seems that durable writeIntentApplication, the process that is triggered
> by sending txCleanupCmd will be durable because of raftClient inner
> implementation, apparently new topologyAwareRaftClient and special recovery
> procedures on primary re-election that will be covered by separate ticket, so
> nothing to do here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
