Re: [infinispan-dev] ISPN-2164 Why does a conditional remove (on it's own), end up with a write skew check?

On 24 Jul 2012, at 09:54, Galder Zamarreño wrote: >>> >>> >>> IOW, the test now passes because the commit throws an exception in 4 out of 5 threads. But, the test could/should maybe work in such way that no exception was thrown and 4 out of 5 invocations returned false to the checks made (conditional remove returns false, or normal remove returns null). >>> >> It is possible that multiple tx return the same non-null existing value - I've commented more on the JIRA. > > Is it possible under concurrent modification circumstances? > > If you have 5 concurrent removals, one should do the job and the others should be no-ops. IOW, 1/5 of the removes should return non-null and the other 4/5 should return null. This is not the case today. Even it is a bit counterintuitive, with optimistic transactions that's possible though. For example: tx1 and tx2 remove the (k,v) entry concurrently: tx1.remove(k); // "v" is returned as that's what tx1 saw at this time tx2.remove(k); // again "v" is returned, as tx1 hasn't committed anything yet (optimistic transactions) Now during the commit time the writes to k are serialised between tx1 and tx2. The only reliable way in which the user can get this behaviour is by forcing the write skew check through a get first (the workaround describe din ISPN-2164). Now thinking about it, the fact that we return the value to the user during the put is equivalently to a read so it might make sense to perform the write skew check for keys that are put into the cache when unsafeReturn is false (the default) and when the Flag.SKIP_REMOTE_LOOKUP is not used. What do you think?

_______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev