[infinispan-dev] question on read committed semantics

[Paolo Romano]

Even though I am not sure that behaviour a) is strictly mandated by ANSI 
SQL Read Committed Isolation Level, I agree with Jonathan: if a 
transaction is not even guaranteed to see its own writes one may start 
wondering what's the purpose of even calling it a transaction...

On the other hand, once you depart from the road of strong consistency, 
and adopt weaker consistency models, it tends to become a matter of 
interpretation/common practice/personal tastes :)

So my 2 cents: being an isolation guarantee that can be ensured in an 
efficient way, I don't see why one would have to give it up. If that's 
desirable for maximizing data freshness, and there are very weak 
consistency requirements, then why using transactions at all? For 
batching updates at commit time?

     Paolo

On 8/10/12 1:23 PM, Jonathan Halliday wrote:
> 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
>>
>>