Re: [infinispan-dev] inefficient usage of CacheLoader with REPL
On 21 December 2011 12:30, Manik Surtani <manik(a)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