[infinispan-dev] SKIP_CACHE_LOAD and write skew check

[Pedro Ruivo]

The WSC is only performed on the primary owner. But the originator needs 
to keep track of the version read in order to the WSC be performed.

I've changed this behavior for IGNORE_RETURN_VALUE flags, where the 
entry is mark as "not-read" (if it wasn't read before). Then, the WSC is 
skipped for this entry.

I probably should have done the same thing for SKIP_CACHE_LOAD.

CACHE_MODE_LOCAL is other flag that, IMO, shouldn't be supported by 
Transactional Caches.

I agree with Sanne and we should re-check all flags since most of them 
can hurt the data consistency.

On 30-08-2016 11:06, Sanne Grinovero wrote:
> I'm not sure why this specific Flag behaves like this, but it's clear
> that Flags can break many things; I suspect originally they were meant
> to be internal-only, and I got them exposed when as a user I was
> having big performance trouble when doing Put operations of 1GB each
> and the damn thing would load the previous value from the MySQL backed
> Cachestore, while my puts didn't use the return value :)
>
> Maybe it's time to reconsider this and split the flags up in "internal
> ones" and public API flags? It would be nice to limit the damage that
> end users can do, many flags could be taken away, or reshape our APIs
> to not really need so many (for example not having the put method
> return a value, or automating such optimisations with internal magic).
>
> +1 to perform the WSC only on the primary owner, that seems like a severe bug?
>
>
> On 30 August 2016 at 08:30, Radim Vansa <rvansa at redhat.com> wrote:
>> I've noticed that SKIP_CACHE_LOAD flag is ignored when performing the
>> write skew check (the old entry is loaded from cache store), though, it
>> is not ignored (and the entry is not loaded) when there's
>> CACHE_MODE_LOCAL [2]. Is that intended behaviour, or just "conserved" by
>> tests?
>>
>> The flag itself allows to break things [3], so I guess that user sets
>> the flag only when he knows that there is no such entry in cache store
>> and it's safe to not load it.
>>
>> Moreover, I don't understand why the WSC should be performed on
>> originator (or backup owners) [4].
>>
>> Thanks for explanations (I'll try to add them as comments to the code -
>> or make the reasoning more obvious).
>>
>> Radim
>>
>> [1]
>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L132
>> [2]
>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L96
>> [3]
>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/context/Flag.java#L89
>> [4]
>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/api/flags/FlagsEnabledTest.java#L85
>>
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> 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
>