[jira] [Commented] (IGNITE-17578) Transactions: async cleanup processing on tx commit

["Denis Chudov (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-17578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762019#comment-17762019 ] 

Denis Chudov commented on IGNITE-17578:
---------------------------------------

I muted distributed implementations of testBalance under the ticket about tx commands reordering ( IGNITE-20116 ) because sometimes tx update commands go ahead of tx cleanup, assuming they have greater safe time. I also made multiple TC runs to make sure that no other tests have become flaky after these changes.

> 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
>            Assignee: Denis Chudov
>            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 application and locks release process should be inverted.
> 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)