[
https://issues.apache.org/jira/browse/IGNITE-21112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-21112:
---------------------------------------
Description:
A. Each node should handle the following message:
RwTransactionsFinishedRequest; it will have targetSchemaVersion field of type
int (which represents a Catalog version). The response will be
RwTransactionsFinishedResponse containing the only field: finished (of type
boolean).
B. When the node gets such a request, it should (1) first check whether the
target version has activated (not just appeared in the local Catalog) on the
node. If not, (2) it should return false. If it has already been activated on
the node, then the node should atomically query its TxManager whether it has
any non-finished RW transactions that started on schema versions preceding the
target version (this is determined by the beginTs of the transaction).
C. To avoid a race between starting an RW transaction and checking for
non-finished transactions, we need to start RW transactions in the following
way:
# beginTs = HLC.now()
# {*}Without doing a schema sync{*}, find the Catalog version active at
beginTs, assign it to TxCatalogVersion
# Atomically wrt checking for transactions existence on schemas before X (see
B.2), wrt finishing RW transactions and wrt raising the 'latest activated
Catalog version' (used in B.1), add the new transaction with beginTs to the map
of the currently active transactions (only if the 'latest activated Catalog
version' is not higher than TxCatalogVersion)
# If on item 3 it turned out that TxCatalogVersion is already lower than the
'latest activated Catalog version', goto step 1
Note that, as on step 2 we don't do schema sync, resolving the catalog version
corresponding to the beginTs might yield different results, so we might
increment one counter and decrement another counter for the same transaction.
To avoid this, we could resolve the 'catalog version for counter' just once
(when incrementing) and store it (for instance, in TxStateMeta).
was:
A. Each node should handle the following message:
RwTransactionsFinishedRequest; it will have targetSchemaVersion field of type
int (which represents a Catalog version). The response will be
RwTransactionsFinishedResponse containing the only field: finished (of type
boolean).
B. When the node gets such a request, it should (1) first check whether the
target version has activated (not just appeared in the local Catalog) on the
node. If not, (2) it should return false. If it has already been activated on
the node, then the node should atomically query its TxManager whether it has
any non-finished RW transactions that started on schema versions preceding the
target version (this is determined by the beginTs of the transaction).
C. To avoid a race between starting an RW transaction and checking for
non-finished transactions, we need to start RW transactions in the following
way:
# beginTs = HLC.now()
# {*}Without doing a schema sync{*}, find the Catalog version active at
beginTs, assign it to TxCatalogVersion
# Atomically wrt checking for transactions existence on schemas before X (see
B.2), wrt finishing RW transactions and wrt raising the 'latest activated
Catalog version' (used in B.1), add the new transaction with beginTs to the map
of the currently active transactions (only if the 'latest activated Catalog
version' is not higher than TxCatalogVersion)
# If on item 3 it turned out that TxCatalogVersion is already lower than the
'latest activated Catalog version', goto step 1
> Mechanism to wait for completion of transactions started on schema versions
> preceding a target schema version
> -------------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-21112
> URL: https://issues.apache.org/jira/browse/IGNITE-21112
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
>
> A. Each node should handle the following message:
> RwTransactionsFinishedRequest; it will have targetSchemaVersion field of type
> int (which represents a Catalog version). The response will be
> RwTransactionsFinishedResponse containing the only field: finished (of type
> boolean).
> B. When the node gets such a request, it should (1) first check whether the
> target version has activated (not just appeared in the local Catalog) on the
> node. If not, (2) it should return false. If it has already been activated on
> the node, then the node should atomically query its TxManager whether it has
> any non-finished RW transactions that started on schema versions preceding
> the target version (this is determined by the beginTs of the transaction).
> C. To avoid a race between starting an RW transaction and checking for
> non-finished transactions, we need to start RW transactions in the following
> way:
> # beginTs = HLC.now()
> # {*}Without doing a schema sync{*}, find the Catalog version active at
> beginTs, assign it to TxCatalogVersion
> # Atomically wrt checking for transactions existence on schemas before X
> (see B.2), wrt finishing RW transactions and wrt raising the 'latest
> activated Catalog version' (used in B.1), add the new transaction with
> beginTs to the map of the currently active transactions (only if the 'latest
> activated Catalog version' is not higher than TxCatalogVersion)
> # If on item 3 it turned out that TxCatalogVersion is already lower than the
> 'latest activated Catalog version', goto step 1
> Note that, as on step 2 we don't do schema sync, resolving the catalog
> version corresponding to the beginTs might yield different results, so we
> might increment one counter and decrement another counter for the same
> transaction. To avoid this, we could resolve the 'catalog version for
> counter' just once (when incrementing) and store it (for instance, in
> TxStateMeta).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
