[infinispan-dev] inefficient usage of CacheLoader with REPL

[Manik Surtani]

On 21 Dec 2011, at 11:56, Sanne Grinovero wrote:

> On 21 December 2011 12:30, Manik Surtani <manik at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org