[
https://issues.jboss.org/browse/ISPN-3451?page=com.atlassian.jira.plugin....
]
Mircea Markus commented on ISPN-3451:
-------------------------------------
Even if the entries would be committed in a defined order in which they hace been written,
the problem still exists due to Infinispan's distributed nature.
For simplicity let's consider that both A and B are owned by N1 and N2.
There is a moment in which the TX is committed on N2 but not yes committed on N1.
All the tx that would read the data from N2 would see the new value, the others seeing the
old one.
If the users really require this semantic, they should use Flag.FORCE_WRITE_LOCK on read
operations as well.
Possible that [~pruivo]'s GMU to handle this scenario implicitly, Pedro care to
comment?
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