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

[Mircea Markus]

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?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20120724/7ff707aa/attachment.html