Phil,

Sorry if it took me a while to get back to this.  This isn't really a problem - as proved by this unit test:

http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/test/java/org/infinispan/loaders/CacheLoaderFunctionalTest.java - see testLoadingToMemory()

The explanation is a very poorly named internal method - CacheLoaderInterceptor.putLoadedEntryInContainer() - which is misleading.  This method is not supposed to store the entry but simply to notify listeners.  (Perhaps it did store the entry once upon a time, but has since then been refactored).  

The actual storage of the entry happens when the entry is wrapped for writing (CacheLoaderInterceptor line 141) which stores the entry in the caller's invocation context.  The actual flushing to memory storage happens in the LockingInterceptor (in cleanupLocks()) when the call returns and locks are released.  Loading from a CacheStore will inevitably involve acquiring write locks on the in-memory data structure so this is the logical place to flush writes and release locks.

On 20 Apr 2010, at 15:43, Philippe Van Dyck wrote:

Done, https://jira.jboss.org/jira/browse/ISPN-407

Cheers,

Phil

P.S.: I sometimes wonder if anyone actually use Infinispan ;-)

Keep wondering.  :)

Cheers
Manik
--
Manik Surtani
Lead, Infinispan
Lead, JBoss Cache