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

Alexander Lapin 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 check txnState 
along with adjusting HLC timestamp on txnStates group. If transaction occurred 
to be
 * pending (there is no explicit txnState for given txnId specified in 
writeIntent) or txnState is ABORTED - writeIntent ignored.
 * COMMITTED - writeInent returned as RO read response.

Please pay attention that, as was mentioned above, besides writeIntent 
resolution itself, it's required to adjust HLC timestamp on txnState partition 
in order to guarantee RO reads and tx commit linearizability, meaning that it's 
illegal to commit transaction with commitTimestamp less or equal to RO 
timestamp that already resolved corresponding writeInent as pending. It's not 
only required to perform timestamp adjustment but it's also important to do it 
atomically to txnState switch.  

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.

  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 check 
[txnState|https://issues.apache.org/jira/browse/IGNITE-16882] along with 
[adjusting HLC timestamp|https://issues.apache.org/jira/browse/IGNITE-17222] on 
txnStates group. If transaction occurred to be
 * pending (there is no explicit txnState for given txnId specified in 
writeIntent) or txnState is ABORTED - writeIntent ignored.
 * COMMITTED - writeInent returned as RO read response.

Please pay attention that, as was mentioned above, besides writeIntent 
resolution itself, it's required to adjust HLC timestamp on txnState partition 
in order to guarantee RO reads and tx commit linearizability, meaning that it's 
illegal to commit transaction with commitTimestamp less or equal to RO 
timestamp that already resolved corresponding writeInent as pending. It's not 
only required to perform timestamp adjustment but it's also important to do it 
atomically to txnState switch.  


> 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 check 
> txnState along with adjusting HLC timestamp on txnStates group. If 
> transaction occurred to be
>  * pending (there is no explicit txnState for given txnId specified in 
> writeIntent) or txnState is ABORTED - writeIntent ignored.
>  * COMMITTED - writeInent returned as RO read response.
> Please pay attention that, as was mentioned above, besides writeIntent 
> resolution itself, it's required to adjust HLC timestamp on txnState 
> partition in order to guarantee RO reads and tx commit linearizability, 
> meaning that it's illegal to commit transaction with commitTimestamp less or 
> equal to RO timestamp that already resolved corresponding writeInent as 
> pending. It's not only required to perform timestamp adjustment but it's also 
> important to do it atomically to txnState switch.  
> 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.



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

Reply via email to