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

[Galder Zamarreño]

Mircea, one last thing. Why is there a check for local here?

https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/interceptors/locking/OptimisticLockingInterceptor.java#L95

That basically means that concurrent cluster wide conditional removes won't work with OL + RR + writeSkew.

Is there a reason why you added this local check?

On Jul 24, 2012, at 4:31 PM, Galder Zamarreño wrote:

> 
> 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache