[
https://issues.apache.org/jira/browse/IGNITE-17578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17578:
-------------------------------------
Description:
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.
was:
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.
> 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 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)
