On 21 Dec 2011, at 11:56, Sanne Grinovero wrote:
On 21 December 2011 12:30, Manik Surtani <manik(a)jboss.org>
wrote:
> Interesting thread. I think this is what we should do, given that the
> ResponseGenerator already bypasses serialising unnecessary return values.
>
> Further, I think loading from a cache store is entirely unnecessary for the
> remote node, for both REPL and DIST, except:
>
> * Until we have
https://issues.jboss.org/browse/ISPN-317 implemented. In
> which case (only) the primary owner/coordinator will still need to load from
> store.
Not sure I see why, especially with REPL. If your thoughts are related
to locking, we should be able to lock the key for the duration of
atomic operations or transactions without actually loading the entry
from slow-store.
Yes, this would be unnecessary with REPL. This was more for DIST.
> * We are using write skew checks, and have eviction enabled.
Again in which
> case only the primary owner/coordinator will still need to load from store,
> to be able to perform a version comparison.
Right I forgot we have write skew checks now. But we should need this
only when they are enabled.
Yes.
More importantly, should we change the "schema" of CacheLoader to
store the version as well?
It does already - since it stores serialised InternalCacheValues.
So that the CacheLoader API can load version information without
loading the value.
Hmm - that would be a change to the CacheLoader SPI, but certainly interesting/worthwhile.
New JIRA?
Both for this case and the above one (locking an entry without loading
it), it might make sense to have cache entries in the container
optionally having a marker like "value not here - load from CacheStore
in case of need".
> In all other cases loading from the cache store should not happen on the
> remote node! :)
>
> I'll take a look at the size/complexity/risk of such a patch, but any more
> thoughts from you guys will be much appreciated.
>
> Cheers
> Manik
Awesome, thanks
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org