[infinispan-dev] SKIP_CACHE_LOAD and write skew check

[Dan Berindei]

+1 to honor it. I should have done it back when I did ISPN-5643 [1],
but I guess I was afraid about breaking more tests.

Note that before ISPN-5643 conditional writes also used to ignore
SKIP_CACHE_LOAD, and the javadoc encouraged users to enable it
together with SKIP_REMOTE_LOOKUP.

[1]: https://issues.jboss.org/browse/ISPN-5643

Cheers
Dan


On Tue, Aug 30, 2016 at 1:59 PM, Radim Vansa <rvansa at redhat.com> wrote:
> 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev