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
