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