[
https://issues.apache.org/jira/browse/IGNITE-20041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-20041:
--------------------------------------------
Assignee: Kirill Sizov
> Asynchronous writeIntent cleanup on write intent resolution
> -----------------------------------------------------------
>
> Key: IGNITE-20041
> URL: https://issues.apache.org/jira/browse/IGNITE-20041
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Assignee: Kirill Sizov
> Priority: Major
> Labels: ignite-3, transaction3_recovery, transactions
>
> h3. Motivation
> Both to handle commit partition failure and data node restart, it's required
> to cleanup local writeIntents in order to eliminate excessive write intent
> resolutions. It's not a matter of correctness, it's a matter of optimization.
> h3. Definition of Done
> * Firstly, after write intent resolution, both coordinator path and commit
> partition path, it's required to change local state fot the corresponding
> transaction to either ABORTED or COMMITED in txnStateMap if
> writeIntentResolution outcome is ABORTED or COMMITED. That will allow
> switching all further writeIntentResolutions from a given node for
> corresponding transaction to a local path that is of course much faster.
> * An asynchronous task should be scheduled that will cleanup given write
> intent by either committing or aborting it.
> h3. Implementation Notes
> * Earlier we've agreed that only RW transactions should cleanup
> writeIntents, however I believe it's no longer reasonable, meaning that both
> RW and RO should do this.
> * In order to minimize the effect of side write intents cleanup on
> transaction execution flow, we must perform this (and any other) write
> intents cleanup asynchronously in a special pool.
> * Write intent cleanup should be fully idempotent, meaning, that two
> separate transactions may touch the same write intent and start the cleanup.
> One of them will win and actually do the cleanup, another will result in
> no-op.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
