From an email sent by Manik on infinispan-dev:

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

This JIRA is about implementing 2nd suggestion as per description.