a) v1. A transaction's own uncommitted writes have precedence over
other values. Transactions are isolated from one another, not from
themselves. That's roughly why ORMs flush any buffered sql to the
database before running queries in the middle of a transaction.
Jonathan.
On 08/10/2012 01:13 PM, Mircea Markus wrote:
Hi,
Ales raised a rather interesting problem around read committed' semantics.
We have read_committed cache, and two concurrent transactions running as follows:
1. tx1:: cache.put(k,v1);
2. tx2:: cache.put(k, v2);
3. tx2:: commit(); //the entry is now (k, v2)
4. tx1 :: cache.get(k);
Now what should the get at returned at step 4?
a) v1 -> the value in the current transaction scope? (current behaviour)
b) v2, as the isolation level is read committed and v2 is the last committed value
c) would make sense to be able to switch between a) and b) on a per cache(config)/per
invocation(flag) basis?
Any oppinion much appreciated!
Cheers,
Mircea
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)