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/i...
- 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
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org