[infinispan-issues] [JBoss JIRA] (ISPN-3451) Read-after-write semantics in transactional mode
[
https://issues.jboss.org/browse/ISPN-3451?page=com.atlassian.jira.plugin....
]
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