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(a)redhat.com&gt; 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/o... > [2] > https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o... > [3] > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... > [4] > https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o... > > > -- > Radim Vansa <rvansa(a)redhat.com&gt; > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)redhat.com&gt; 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/o... >>> [2] >>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o... >>> [3] >>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... >>> [4] >>> https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o... >>> >>> >>> -- >>> Radim Vansa <rvansa(a)redhat.com&gt; >>> JBoss Performance Team >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev