On 17 Jun 2013, at 13:58, Pedro Ruivo <[email protected]> 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) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
