[infinispan-dev] inefficient usage of CacheLoader with REPL

[Manik Surtani]

Also see https://issues.jboss.org/browse/ISPN-1642 and https://github.com/infinispan/infinispan/pull/761 :-)

On 21 Dec 2011, at 12:29, Manik Surtani wrote:

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20111221/5239efdc/attachment-0001.html