[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