Re: [infinispan-dev] inefficient usage of CacheLoader with REPL

On 21 Dec 2011, at 11:56, Sanne Grinovero wrote: > On 21 December 2011 12:30, Manik Surtani <manik(a)jboss.org&gt; 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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev