[infinispan-issues] [JBoss JIRA] (ISPN-3451) Read-after-write semantics in transactional mode

[Pedro Ruivo (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12800300#comment-12800300 ] 

Pedro Ruivo commented on ISPN-3451:
-----------------------------------

True, GMU achieves (Extended-) Updated Serializability. So, if you have a read operation, you will see both A and B equals to 1 or A and B equals to 2 depending if your tx starts after or before the commit of the write transaction.

Of course we have the cost of keeping multiple versions for a key in the data container and more restrict validation phase. Also, read-only transactions can read a old snapshot (i.e. it's not the most recent). but that snapshot is always consistent! 
                
> Read-after-write semantics in transactional mode
> ------------------------------------------------
>
>                 Key: ISPN-3451
>                 URL: https://issues.jboss.org/browse/ISPN-3451
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 6.0.0.Alpha3
>            Reporter: Radim Vansa
>            Assignee: Mircea Markus
>
> In dist sync tx (optimistic, read committed) mode I'd expect that in this situation:
> A=1, B=1
> startTx
> write A=2
> write B=2
> endTx
> if on different node I read B=2, it implies that A=2.
> However, as entries are committed during the commit phase in non-defined order (according to context map iteration order), it may happen that B is committed to 2, B is read as 2, A is read as 1 and only after that A is committed to 2.
> That is pretty unexpected semantics. It even means that the transactions are not atomic with regards to read operations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira