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

On Jul 24, 2012, at 1:55 PM, Mircea Markus wrote: > > 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? Plus, when OL is in use, but this is already part of the OptimisticLockingInterceptor. Sounds good to me. I'll document this better in the code. > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev