[infinispan-dev] Doubts about TxDistributionInterceptor and possible break in transaction isolation

Mircea Markus mmarkus at redhat.com
Mon Jun 17 09:46:12 EDT 2013


On 17 Jun 2013, at 13:58, Pedro Ruivo <pedro at infinispan.org> wrote:

>>> 
>>> After this analysis, it is possible to break the isolation between
>>> transaction if I do a get on the key that does not exist:
>>> 
>>> tm.begin()
>>> cache.get(k) //returns null
>>> //in the meanwhile a transaction writes on k and commits
>>> cache.get(k) //return the new value. IMO, this is not valid for
>>> REPEATABLE_READ isolation level!
>> 
>> Indeed sounds like a bug, well spotted.
>> Can you please add a UT to confirm it and raise a JIRA?
> 
> created: https://issues.jboss.org/browse/ISPN-3236
> 
> IMO, this should be the correct behaviour (I'm going to add the test 
> cases later):
> 
> tm.begin()
> cache.get(k) //returns null (op#1)
> //in the meanwhile a transaction writes on k and commits
> write operation performed:
> * put: must return the same value as op#1
> * conditional put //if op#1 returns null the operation should be always 
> successful (i.e. the key is updated, return true). Otherwise, the key 
> remains unchanged (return false)
> * replace: must return the same value as op#1
> * conditional replace: replace should be successful if checked with the 
> op#1 return value (return true). Otherwise, the key must remain 
> unchanged (return false).
all the conditional operation should consider as existing value whatever was previously read (op#1) or more correctly whatever it is in the context:
e.g. 
//start k = null
tx.begin()
cache.put(k,v1);
cache.replace(k,v1, v2) -> should succeed as the context sees v1 associated to k 
> * remote: must return the same value as op#1
you mean remove? remove should use whatever is in the context
> * conditional remove: the key should be removed if checked with the op#1 
> return value (return true). Otherwise, the key must remain unchanged 
> (return false)
same..
> 
> Also, the description above should be valid after a removal of a key.

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list