[infinispan-dev] SKIP_CACHE_LOAD and write skew check

[Radim Vansa]

On 08/30/2016 12:52 PM, Pedro Ruivo wrote:
> 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.

I think there are valid use cases for skipping the cache load, and it's 
hidden well enough that users won't use that just accidentally. But I 
don't see any opinions if the WSC should honor or ignore this flag (I 
would honor it).

Radim

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


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team