[
https://issues.apache.org/jira/browse/IGNITE-20700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20700:
-------------------------------------
Description:
h3. Motivation
Transaction coordinator should properly handle:
* All kind of exceptions that might be thrown during sending finish request
and finish response awaiting.
* Commit partition primary replica changes.
* Including dedicated scenario of commit partition recovery after commit
partition majority loss.
h3. Definition of Done
Transaction finish request is sent in a durable manner.
h3. Implementation Notes
* Commit timestamp, tx outcome (commit/abort), enlisted paritions set, etc are
calculated once only and do not change over retries.
* Recipient on the other hand may change, and should be evaluated as
PD.awaitPrimaryReplica(commitPartition). Thus, we will handle both primary
replica changes and commit partition recovery after majority loss.
* On the commit partition side, finish request should await for all locks to
be released (see lock released flag in txnState).
* It's possible for finish request to see a terminated transaction with
another outcome, meaning that recovery logic (that's not yet implemented) will
rollback the transaction while finish request contains commit as the desired
outcome. In that case, we expect the user to receive a tx-was-rolled-back
exception. Any consecutive user calls, both commit and rollback should not
throw exceptions.
> Implement durable transaction coordinator finish
> ------------------------------------------------
>
> Key: IGNITE-20700
> URL: https://issues.apache.org/jira/browse/IGNITE-20700
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
>
> h3. Motivation
> Transaction coordinator should properly handle:
> * All kind of exceptions that might be thrown during sending finish request
> and finish response awaiting.
> * Commit partition primary replica changes.
> * Including dedicated scenario of commit partition recovery after commit
> partition majority loss.
> h3. Definition of Done
> Transaction finish request is sent in a durable manner.
> h3. Implementation Notes
> * Commit timestamp, tx outcome (commit/abort), enlisted paritions set, etc
> are calculated once only and do not change over retries.
> * Recipient on the other hand may change, and should be evaluated as
> PD.awaitPrimaryReplica(commitPartition). Thus, we will handle both primary
> replica changes and commit partition recovery after majority loss.
> * On the commit partition side, finish request should await for all locks to
> be released (see lock released flag in txnState).
> * It's possible for finish request to see a terminated transaction with
> another outcome, meaning that recovery logic (that's not yet implemented)
> will rollback the transaction while finish request contains commit as the
> desired outcome. In that case, we expect the user to receive a
> tx-was-rolled-back exception. Any consecutive user calls, both commit and
> rollback should not throw exceptions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
