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.
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> 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>
> 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