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

[Galder Zamarreño]

I created https://issues.jboss.org/browse/ISPN-2199

On Aug 8, 2012, at 7:37 PM, Sanne Grinovero wrote:

> Good explanation, I totally agree. Using SKIP_REMOTE_LOOKUP will
> always include some degree of inconsistent behaviour depending on the
> node it is run on, and as such is obviously reserved for very special
> use cases and only for users who understand the implications.
> 
> We discussed a year ago about introducing an API safe version of
> IGNORE_RETURN_VALUES, which resulted in the Jokre project
> https://github.com/infinispan/jokre
> 
> This isn't much active anymore as I was told that the JSR will have
> put() and other write operations having an explicit void return type.
> 
> Anyway, +1 from me to introduce a IGNORE_RETURN_VALUES flag to be used
> today and as internal building block for these operations in the
> future.
> 
> On 6 August 2012 14:09, Mircea Markus <mircea.markus at jboss.com> wrote:
>> Very good point.
>> I rdeplied inline:
>> https://github.com/infinispan/infinispan/pull/1221#discussion_r1310710
>> 
>> On 6 Aug 2012, at 11:27, Sanne Grinovero wrote:
>> 
>> I didn't read all the details on the optimistick lock implementation,
>> but want to warn here against the interpretation of the
>> SKIP_REMOTE_LOOKUP flag for these purposes; it should only apply on
>> REMOTE lookups, not imply a general-purpose "I'm ignoring the return
>> value", that would be misleading for users as it's not how things
>> work, it's not automatically implying for example also a skip from
>> cache stores or even a local data container GET hit.. which could
>> affect access statistics and eviction decisions.
>> 
>> https://github.com/infinispan/infinispan/pull/1221#r1310549
>> 
>> On 25 July 2012 14:27, Mircea Markus <mircea.markus at jboss.com> wrote:
>> 
>> 
>> 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.
>> 
>> 
>> 
>> _______________________________________________
>> 
>> infinispan-dev mailing list
>> 
>> infinispan-dev at lists.jboss.org
>> 
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> 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