[
https://issues.apache.org/jira/browse/IGNITE-20041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20041:
-------------------------------------
Description:
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.
was:
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 clean up given write
intent by either committing or aborting it.
h3. Implementation Notes
* Earlier we've agreed that only RW transactions should clean up 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 transactions write intent resolution
cleanup we may introduce special pool that will handle all write intents
cleanup actions, that
> Asynchronous cleanup writeIntent on write intent resolution
> -----------------------------------------------------------
>
> Key: IGNITE-20041
> URL: https://issues.apache.org/jira/browse/IGNITE-20041
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> 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)
