[
https://issues.apache.org/jira/browse/IGNITE-24343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-24343:
-------------------------------------
Description:
h3. Motivation
Side note: we are not consistent in what commitPartitionId means: usually we
assume that it's tableId + partitionIndex however in storage API, e.g. in
PartitionDataStorage#addWrite commitPartitionId itself means partition index
along with dedicated
commitTableId. Below I will assume that commitPartitionId is a combination of
table/zoneId and partitionIndex.
* CommitPartition is a partition where where persisted txnState is stored.
The state is atomically switched within TxFinish transaction phase.
* CommitPartitionId is used in order to evaluate writeIntents through
commitPartition path.
* Write Intent(WI) resolution is a process that allows to define whether WI
should be considered as applied (either committed or aborted) or ignored
because corresponding transaction is in PENDING state. Simply, for WI(txId)
** Tx(txId).isPending() -> ignore WI (return previous value, or null if
there's no such value).
** Tx(txId).isAborted() -> ignore WI (return previous value, or null if
there's no such value).
** Tx(txId).isCommited() -> consider WI as a common value.
* There are 3 different pathes of WI Resolution:
** Local path. Every node that participates in tx flow has volatile
txnStateMap, thus it worth checking locally whether we already know the state
of corresponding transaction.
** If local path is not applicable we will use Coordinator Path by requesting
txn state from cooresponding coordinator.
** If Coordinator Path also not applicable we will use Commit Partition Path.
Hence it's required to know where commit partition is.
** For more details please check
[IEP-91|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211885498#IEP91:Transactionprotocol-ROtransactions.1]
Worth mentioning that IEP is a bit outdated and both RO and RW transaction may
see WI and thus do WI Resolution.
Seems that we are done with [taxidermy|https://en.wikipedia.org/wiki/Taxonomy].
h3. Definition of Done
* Within collocation track we do store zoneId + partitionIndex as
commitPartitionId instead of tablerId + partitionIndex.
* WI resolution works on top of ZonePartitionId as commitPartitionId.
was:
h3. Motivation
Side note: we are not consistent in what commitPartitionId means: usually we
assume that it's tableId + partitionIndex however in storage API, e.g. in
PartitionDataStorage#addWrite commitPartitionId itself means partition index
along with dedicated
commitTableId. Below I will assume that commitPartitionId is a combination of
table/zoneId and partitionIndex.
* CommitPartition is a partition where where persisted txnState is stored.
The state is atomically switched within TxFinish transaction phase.
* CommitPartitionId is used in order to evaluate writeIntents through
commitPartition path.
* Write Intent(WI) resolution is a process that allows to define whether WI
should be considered as applied (either committed or aborted) or ignored
because corresponding transaction is in PENDING state. Simply, for WI(txId)
** Tx(txId).isPending() -> ignore WI (return previous value, or null if
there's no such value).
** Tx(txId).isAborted() -> ignore WI (return previous value, or null if
there's no such value).
** Tx(txId).isCommited() -> consider WI as a common value.
* There are 3 different pathes of WI Resolution:
** Local path. Every node that participates in tx flow has volatile
txnStateMap, thus it worth checking locally whether we already know the state
of corresponding transaction.
** If local path is not applicable we will use Coordinator Path by requesting
txn state from cooresponding coordinator.
** If Coordinator Path also not applicable we will use Commit Partition Path.
Hence it's required to know where commit partition is.
** For more details please check
[IEP-91|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211885498#IEP91:Transactionprotocol-ROtransactions.1]
Worth mentioning that IEP is a bit outdated and both RO and RW transaction may
see WI and thus do WI Resolution.
Seems that we are done with [taxidermy|https://en.wikipedia.org/wiki/Taxonomy].
> Use ZonePartitionId as commitPartitionId
> ----------------------------------------
>
> Key: IGNITE-24343
> URL: https://issues.apache.org/jira/browse/IGNITE-24343
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Side note: we are not consistent in what commitPartitionId means: usually we
> assume that it's tableId + partitionIndex however in storage API, e.g. in
> PartitionDataStorage#addWrite commitPartitionId itself means partition index
> along with dedicated
> commitTableId. Below I will assume that commitPartitionId is a combination of
> table/zoneId and partitionIndex.
> * CommitPartition is a partition where where persisted txnState is stored.
> The state is atomically switched within TxFinish transaction phase.
> * CommitPartitionId is used in order to evaluate writeIntents through
> commitPartition path.
> * Write Intent(WI) resolution is a process that allows to define whether WI
> should be considered as applied (either committed or aborted) or ignored
> because corresponding transaction is in PENDING state. Simply, for WI(txId)
> ** Tx(txId).isPending() -> ignore WI (return previous value, or null if
> there's no such value).
> ** Tx(txId).isAborted() -> ignore WI (return previous value, or null if
> there's no such value).
> ** Tx(txId).isCommited() -> consider WI as a common value.
> * There are 3 different pathes of WI Resolution:
> ** Local path. Every node that participates in tx flow has volatile
> txnStateMap, thus it worth checking locally whether we already know the state
> of corresponding transaction.
> ** If local path is not applicable we will use Coordinator Path by
> requesting txn state from cooresponding coordinator.
> ** If Coordinator Path also not applicable we will use Commit Partition
> Path. Hence it's required to know where commit partition is.
> ** For more details please check
> [IEP-91|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211885498#IEP91:Transactionprotocol-ROtransactions.1]
> Worth mentioning that IEP is a bit outdated and both RO and RW transaction
> may see WI and thus do WI Resolution.
>
> Seems that we are done with
> [taxidermy|https://en.wikipedia.org/wiki/Taxonomy].
> h3. Definition of Done
> * Within collocation track we do store zoneId + partitionIndex as
> commitPartitionId instead of tablerId + partitionIndex.
> * WI resolution works on top of ZonePartitionId as commitPartitionId.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
