You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by " Kirill Sizov (Jira)" <ji...@apache.org> on 2023/11/08 09:06:00 UTC
[jira] [Updated] (IGNITE-20700) Implement durable transaction coordinator finish
[ https://issues.apache.org/jira/browse/IGNITE-20700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kirill Sizov updated IGNITE-20700:
-----------------------------------
Reviewer: Denis Chudov
> 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
> Assignee: Kirill Sizov
> Priority: Major
> Labels: ignite-3
> Time Spent: 8h
> Remaining Estimate: 0h
>
> 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)