[infinispan-dev] inefficient usage of CacheLoader with REPL

[Sanne Grinovero]

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.

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

More importantly, should we change the "schema" of CacheLoader to
store the version as well?
So that the CacheLoader API can load version information without
loading the value.

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