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

[Radim Vansa (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Vansa updated ISPN-3451:
------------------------------

    Description: 
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.

  was:
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. I suggest that the context should use some different structure (linked hash map?) which will be iterated according to the modification order.

Although, this still wouldn't assure the atomicity of transaction for some scenarios.


    
> 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