[infinispan-dev] ClusteredGet and direct operations on a cacheloader

[Manik Surtani]

Mircea

Regarding direct loading from a cache loader in the  
ClusteredGetCommand, this is an issue since a) it does not acquire any  
locks to put this value back in the data container, and b) probably as  
a consequence of a), doesn't bother to put any looked up value in the  
data container at all.

This is inefficient since multiple CGCs on the same key (coming from  
different cache instances in a cluster) would cause the owning cache  
to load this several times repeatedly from a loader.

I see this problem with DIST since I use CGC to load an entry from a  
remote cache and if L1 caching is disabled on the requesting cache,  
multiple uses of an entry will result in this entry being read off a  
loader repeatedly.  Which is no good.  :-)

So I think the CGC's perform() method should actually be doing a  
cache.get() - or something very similar - where the entire interceptor  
chain is invoked and locks are acquired, entries moved to the data  
container if loaded, etc., and metrics on cache hits/misses properly  
updated.  The challenges here are, of course:

1.  The ping-pong effect.  So we need to make sure any clustered cache  
loader or the DistributionInterceptor do not try and load this from  
elsewhere in the cluster.  Easily solved with the isOriginLocal flag  
on the context.
2.   Making sure we get an InternalCacheEntry and not just a value to  
return.  This is trickier since ICEs are not exposed via public APIs  
at all.  Perhaps we need a separate, non-replicable Command for this  
purpose - maybe a subclass of GetKeyValueCommand  
(GetCacheEntryCommand?) which (a) cannot be replicated and (b) will  
return the ICE.

So, CGC would create a GCEC and pass it up the interceptor chain, and  
retrieve the ICE from the GCEC after the call returns?

WDYT?
--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org