+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 <rva...@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 <rva...@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 <rva...@redhat.com> >>>> JBoss Performance Team >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa <rva...@redhat.com> > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
