Bug 1002602 - Read-after-write semantics in transactional mode
Read-after-write semantics in transactional mode
Status: CLOSED NOTABUG
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan (Show other bugs)
6.2.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tristan Tarrant
Martin Gencur
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-29 10:00 EDT by Radim Vansa
Modified: 2013-08-29 11:07 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-29 11:07:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker ISPN-3451 Major Resolved Read-after-write semantics in transactional mode 2013-09-12 06:28:57 EDT

  None (edit)
Description Radim Vansa 2013-08-29 10:00:29 EDT
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.
Comment 2 JBoss JIRA Server 2013-08-29 10:35:28 EDT
Mircea Markus <mmarkus@redhat.com> made a comment on jira 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?
Comment 3 JBoss JIRA Server 2013-08-29 10:35:42 EDT
Mircea Markus <mmarkus@redhat.com> updated the status of jira ISPN-3451 to Resolved
Comment 4 JBoss JIRA Server 2013-08-29 10:45:49 EDT
Pedro Ruivo <pedroruivo2@gmail.com> made a comment on jira 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!

Note You need to log in before you can comment on or make changes to this bug.