[infinispan-dev] question on read committed semantics

[Jonathan Halliday]

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 at 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)