This is an optimisation (believe it or not) in the CacheLoaderInterceptor [1]. Let me explain. CLI contains a method, loadIfNeeded() (line 113). Here is the interesting bit: if (!loader.containsKey(key)) { if (log.isTraceEnabled()) log.trace("No need to load. Key doesn't exist in the loader."); return false; } .... loadEntry(ctx, key, n); So, the optimisation is to actually check that the entry exists in the store prior to calling load, as this often saves on unmarshalling the value, etc, especially if the entry has expired (since loader.containsKey() on an expired value will return false). Now the problem you see lies in the AbstractCacheLoader[2] where the *default* impl of containsKey() does ... loadEntry() ! So yes, this is crappy and implementations should be much smarter about this. E.g., a JDBC cache store could be much more efficient in a query for containsKey() than a heavy-handed load. Similarly, this applies to all other CacheStore impls. So, yes I agree that the CacheStore *implementations* are inefficient in this regard. I have created ISPN-337 [3] for this, thanks for reporting. Cheers Manik [1] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i... [2] http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i... [3] https://jira.jboss.org/jira/browse/ISPN-337 On 18 Jan 2010, at 17:48, Galder Zamarreno wrote: -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org