[infinispan-dev] inefficient usage of CacheLoader with REPL

[Sanne Grinovero]

On 21 December 2011 13:29, Manik Surtani <manik at jboss.org> 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.

Sorry for my bad wording. I mean to store them explicitly in a
separate "field" so that it can be loaded separately from the values.
That's why I'm referring to "schema".

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

I'll create one for this. target 6.0

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