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

[Mircea Markus]

On 25 Jul 2012, at 12:26, Galder Zamarreño wrote:

> 
> On Jul 25, 2012, at 1:14 PM, Mircea Markus wrote:
> 
>> 
>> On 24 Jul 2012, at 20:44, Galder Zamarreño wrote:
>> 
>>> 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?
>> 
>> That code was added with ISPN-1941 and only handles write skew (ws) for local caches, Manik might comment a bit more about it.
>> The code that handles ws for distributed caches is in the VersionedEntryWrappingInterceptor(VEWI).
>> 
>> I don't think that that code you pointed belongs to the OptimisticLockingInterceptor (OLI) for two reasons: the OLI is should handle the locking and write skew checking is an orthogonal concern. Also the rest of write skew checking is handled in the VEWI, so this logic should be placed there as well.  
>> TBH I think write skew check logic deserve its own dedicated interceptor as the code in this area is spread over too many places: OLI, VEWI  and some not nice static methods in the ClusteringDependentLogic. At least for me it is quite hard to follow it as it is now. Wdyt?
> 
> Good points. So, we need a better way of doing write skew checks both local and in cluster, from a more centralized place then?
> 
> Let's see what Manik and others say, but won't be able to properly fix this before I go on holidays. There's a valid workaround for it though, so not massively urgent.
+1. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20120725/5d305485/attachment.html