[ 
https://issues.apache.org/jira/browse/IGNITE-20700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Lapin updated IGNITE-20700:
-------------------------------------
    Labels: ignite-3  (was: )

> 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
>              Labels: ignite-3
>
> 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)

Reply via email to