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

Sergey Uttsel updated IGNITE-17261:
-----------------------------------
    Description: 
Because of lock-free nature, RO reads might interact with writeIntents, meaning 
that such intents should be either evaluated as committed, aborted or pending. 
In order to perform writeIntent resolution it's required to
 * Checks a local txn state map for committed or aborted state - allow read if 
the state is committed and commitTs <= readTs.
 * If not possible, send a TxStateReq  to the txn coordinator - this initiates 
the {*}coordinator path{*}. Coordinator address is fetched from the [txn state 
map|https://docs.google.com/document/d/1PndaylEfK7CPUN7Kv9RYPKASN299s2qlbnMA5xIOFXo/edit#heading=h.wx3zf7jlf156].
 * If a coordinator path was not able to resolve the intent, one of the 
following has happened - the coordinator is dead or txn state is not available 
in the cache. Calculate a commit partition and send the TxStateReq to its 
primary replica - this initiates the {*}commit partition path{*}.
 * Retry commit partition path until a success or timeout.

On receiving TxStateReq on the coordinator:
 * If the local txn is finished, return the response with the outcome: commit 
or abort. The txn state is stored in a local cache, mentioned in the RW section.
 * If the local txn is finishing (waiting for finish state replication), wait 
for outcome and return response with the outcome: commit or abort
 * If the outcome is to commit, additional timestamp check is required: a 
commit timestamp must be <= readTs. If the condition is not held, the outcome 
is changed to commit .
 * If local txn is active, adjust the txn coordinator node HLC according to 
readTs to make sure the txn commit timestamp is above the read timestamp. The 
read timestamp must be installed before txn is started to commit, so commit 
timestamp is assigned after the read timestamp. This must be achieved by some 
sort of concurrency control, preferably non-blocking. In this case we must 
ignore the write intent, so the outcome is to abort.
 * If txn state is not found in a local cache and txn is not active, return 
NULL.

On receiving TxStateReq on commit partition:
 * Read the txn state from the persistent storage. If found, validate a commit 
timestamp (only for committed state) and return the outcome. If not found, 
return NULL outcome in a TxStateResp.

 

There's an open question about following tx design feature: 
https://issues.apache.org/jira/browse/IGNITE-17627

 
{code:java}
If the state is NULL, this means txn is not yet started to finish and its 
outcome is not known. Send TxStateReq(txId,txnReadTs) to the txCoord to trigger 
the coordinator path.{code}
Seems that it's not required, let's discuss it explicitly.

  was:
Because of lock-free nature, RO reads might interact with writeIntents, meaning 
that such intents should be either evaluated as committed, aborted or pending. 
In order to perform writeIntent resolution it's required to
 * Checks a local txn state map for committed or aborted state - allow read if 
the state is committed and commitTs <= readTs.
 * If not possible, send a TxStateReq  to the txn coordinator - this initiates 
the {*}coordinator path{*}. Coordinator address is fetched from the [txn state 
map|https://docs.google.com/document/d/1PndaylEfK7CPUN7Kv9RYPKASN299s2qlbnMA5xIOFXo/edit#heading=h.wx3zf7jlf156].
 * If a coordinator path was not able to resolve the intent, one of the 
following has happened - the coordinator is dead or txn state is not available 
in the cache. Calculate a commit partition and send the TxStateReq to its 
primary replica - this initiates the {*}commit partition path{*}.
 * Retry commit partition path until a success or timeout.

On receiving TxStateReq on the coordinator:
 * If the local txn is finished, return the response with the outcome: commit 
or abort. The txn state is stored in a local cache, mentioned in the RW section.
 * If the local txn is finishing (waiting for finish state replication), wait 
for outcome and return response with the outcome: commit or abort
 * If the outcome is to commit, additional timestamp check is required: a 
commit timestamp must be <= readTs. If the condition is not held, the outcome 
is changed to commit .
 * If local txn is active, adjust the txn coordinator node HLC according to 
readTs to make sure the txn commit timestamp is above the read timestamp. The 
read timestamp must be installed before txn is started to commit, so commit 
timestamp is assigned after the read timestamp. This must be achieved by some 
sort of concurrency control, preferably non-blocking. In this case we must 
ignore the write intent, so the outcome is to abort.
 * If txn state is not found in a local cache and txn is not active, return 
NULL.

On receiving TxStateReq on commit partition:
 * Read the txn state from the persistent storage. If found, validate a commit 
timestamp (only for committed state) and return the outcome. If not found, 
return NULL outcome in a TxStateResp.

 

There's an open question about following tx design feature:
{code:java}
If the state is NULL, this means txn is not yet started to finish and its 
outcome is not known. Send TxStateReq(txId,txnReadTs) to the txCoord to trigger 
the coordinator path.{code}
Seems that it's not required, let's discuss it explicitly.


> Implement write intent resolution logic for RO reads
> ----------------------------------------------------
>
>                 Key: IGNITE-17261
>                 URL: https://issues.apache.org/jira/browse/IGNITE-17261
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Alexander Lapin
>            Priority: Major
>              Labels: ignite-3, transaction3_ro
>         Attachments: Screenshot from 2022-07-06 17-00-26.png
>
>
> Because of lock-free nature, RO reads might interact with writeIntents, 
> meaning that such intents should be either evaluated as committed, aborted or 
> pending. In order to perform writeIntent resolution it's required to
>  * Checks a local txn state map for committed or aborted state - allow read 
> if the state is committed and commitTs <= readTs.
>  * If not possible, send a TxStateReq  to the txn coordinator - this 
> initiates the {*}coordinator path{*}. Coordinator address is fetched from the 
> [txn state 
> map|https://docs.google.com/document/d/1PndaylEfK7CPUN7Kv9RYPKASN299s2qlbnMA5xIOFXo/edit#heading=h.wx3zf7jlf156].
>  * If a coordinator path was not able to resolve the intent, one of the 
> following has happened - the coordinator is dead or txn state is not 
> available in the cache. Calculate a commit partition and send the TxStateReq 
> to its primary replica - this initiates the {*}commit partition path{*}.
>  * Retry commit partition path until a success or timeout.
> On receiving TxStateReq on the coordinator:
>  * If the local txn is finished, return the response with the outcome: commit 
> or abort. The txn state is stored in a local cache, mentioned in the RW 
> section.
>  * If the local txn is finishing (waiting for finish state replication), wait 
> for outcome and return response with the outcome: commit or abort
>  * If the outcome is to commit, additional timestamp check is required: a 
> commit timestamp must be <= readTs. If the condition is not held, the outcome 
> is changed to commit .
>  * If local txn is active, adjust the txn coordinator node HLC according to 
> readTs to make sure the txn commit timestamp is above the read timestamp. The 
> read timestamp must be installed before txn is started to commit, so commit 
> timestamp is assigned after the read timestamp. This must be achieved by some 
> sort of concurrency control, preferably non-blocking. In this case we must 
> ignore the write intent, so the outcome is to abort.
>  * If txn state is not found in a local cache and txn is not active, return 
> NULL.
> On receiving TxStateReq on commit partition:
>  * Read the txn state from the persistent storage. If found, validate a 
> commit timestamp (only for committed state) and return the outcome. If not 
> found, return NULL outcome in a TxStateResp.
>  
> There's an open question about following tx design feature: 
> https://issues.apache.org/jira/browse/IGNITE-17627
>  
> {code:java}
> If the state is NULL, this means txn is not yet started to finish and its 
> outcome is not known. Send TxStateReq(txId,txnReadTs) to the txCoord to 
> trigger the coordinator path.{code}
> Seems that it's not required, let's discuss it explicitly.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to