[
https://issues.jboss.org/browse/ISPN-3451?page=com.atlassian.jira.plugin....
]
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