[
https://issues.apache.org/jira/browse/IGNITE-20033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-20033:
-------------------------------------
Description:
h3. Motivation
For some purposes, in addition to persistent txnState in commit partition, it's
required to have a txn meta on every transactional actor: txn coordinator,
commit partition (both primary and all backups) and all enlisted partitions
(both primary and backups).
[IEP-91|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Txnstatemap]
names such meta holder as txn state map and specifies following structure
{code:java}
txId -> (txState, txCoordAddr, commitTs){code}
Such map is originally designed to provide required information for
writeIntentResolution: txState for local write intent resolution and
txCoordAddr for coordinator-path one, but that's not all it's good for, so it
definitely worth to implement it as soon as possible in order to unblock
further activities.
- Why we have this ticket in "commit partition recovery" pack?
- Because in order to implement proper handling of a commit partition primary
replica change (which is definitely a part of the "commit partition pack") it's
required to:
# Support local txnStateMap, in order to
# Implement writeIntentResolution coordinator path, in order to
# Calculate commitTimestamp on txn coordtinator istead of commit partition,
where we do it now.
h3. Definition of Done
Every transactional actor
* Txn Coordinator.
* CommitPartition, both primary and all backups.
* All enlisted partitions, both primary and all backups.
should have volatile txnStateMap with following suggested structure 'txId ->
(txState, txCoordAddr, commitTs)'.
Given map should be adjusted before any further transactional actions within
node in a following way:
* Transaction coordinator.
** On transaction start with state PENDING.
** On transaction commit, right after commitTimestamp calucalttion with state
FINISHING.
** On txFinishReplicaResponse with either COMMITED or ABORTED.
* Commit partition.
** On replica touch with state PENDING.
** After succefull finishTxCommand application on majoirty with either
COMMITED or ABORTED.
** Seems that we don't need FINISHING state here, so let's skip it for now.
* Enlisted replica.
** Primary
*** On replica touch with state PENDING.
*** On TxCleanupCommand COMMITED or ABORTED.
** Backup
*** On touch replication PENDING.
*** On TxCleanupCommand COMMITED or ABORTED, same as for primary.
h3. Implementation Notes
There are some open questions:
* Where to put this txnStateMap? TxManager?
* Properly handle same map multiple updates, based on the fact that Commit
Partition is also an enlisted partition. To be honest I believe it's not that
important. We may extent possible state change application rules to assume that
null -> PENDING, PENDING -> FINISHING, PENDING -> COMMITED, PENDING -> ABORTED,
COMMITED -> COMMITED and ABORTED -> ABORTED are all possible.
* Eliminate excessive map updates in case of "one-phase commit".
* Substitute org.apache.ignite.internal.tx.impl.TxManagerImpl#states with
txnStateMap.
> Implement local txnStateMap
> ---------------------------
>
> Key: IGNITE-20033
> URL: https://issues.apache.org/jira/browse/IGNITE-20033
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: ignite-3, transaction3_recovery, transactions
>
> h3. Motivation
> For some purposes, in addition to persistent txnState in commit partition,
> it's required to have a txn meta on every transactional actor: txn
> coordinator, commit partition (both primary and all backups) and all enlisted
> partitions (both primary and backups).
> [IEP-91|https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Txnstatemap]
> names such meta holder as txn state map and specifies following structure
>
> {code:java}
> txId -> (txState, txCoordAddr, commitTs){code}
> Such map is originally designed to provide required information for
> writeIntentResolution: txState for local write intent resolution and
> txCoordAddr for coordinator-path one, but that's not all it's good for, so it
> definitely worth to implement it as soon as possible in order to unblock
> further activities.
> - Why we have this ticket in "commit partition recovery" pack?
> - Because in order to implement proper handling of a commit partition primary
> replica change (which is definitely a part of the "commit partition pack")
> it's required to:
> # Support local txnStateMap, in order to
> # Implement writeIntentResolution coordinator path, in order to
> # Calculate commitTimestamp on txn coordtinator istead of commit partition,
> where we do it now.
> h3. Definition of Done
> Every transactional actor
> * Txn Coordinator.
> * CommitPartition, both primary and all backups.
> * All enlisted partitions, both primary and all backups.
> should have volatile txnStateMap with following suggested structure 'txId ->
> (txState, txCoordAddr, commitTs)'.
>
> Given map should be adjusted before any further transactional actions within
> node in a following way:
> * Transaction coordinator.
> ** On transaction start with state PENDING.
> ** On transaction commit, right after commitTimestamp calucalttion with
> state FINISHING.
> ** On txFinishReplicaResponse with either COMMITED or ABORTED.
> * Commit partition.
> ** On replica touch with state PENDING.
> ** After succefull finishTxCommand application on majoirty with either
> COMMITED or ABORTED.
> ** Seems that we don't need FINISHING state here, so let's skip it for now.
> * Enlisted replica.
> ** Primary
> *** On replica touch with state PENDING.
> *** On TxCleanupCommand COMMITED or ABORTED.
> ** Backup
> *** On touch replication PENDING.
> *** On TxCleanupCommand COMMITED or ABORTED, same as for primary.
> h3. Implementation Notes
> There are some open questions:
> * Where to put this txnStateMap? TxManager?
> * Properly handle same map multiple updates, based on the fact that Commit
> Partition is also an enlisted partition. To be honest I believe it's not that
> important. We may extent possible state change application rules to assume
> that null -> PENDING, PENDING -> FINISHING, PENDING -> COMMITED, PENDING ->
> ABORTED, COMMITED -> COMMITED and ABORTED -> ABORTED are all possible.
> * Eliminate excessive map updates in case of "one-phase commit".
> * Substitute org.apache.ignite.internal.tx.impl.TxManagerImpl#states with
> txnStateMap.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
