[jbosscache-issues] [JBoss JIRA] Updated: (JBCACHE-1423) Call to put(Fqn, Map) where Fqn is passivated leads to out of date data

Call to put(Fqn, Map) where Fqn is passivated leads to out of date data ----------------------------------------------------------------------- Key: JBCACHE-1423 URL: https://jira.jboss.org/jira/browse/JBCACHE-1423 Project: JBoss Cache Issue Type: Bug Security Level: Public(Everyone can see) Components: Cache loaders, Eviction Affects Versions: 2.2.1.CR1 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 2.2.1.GA See JBCACHE-1172 for discussion of core problem; this is a variant of that wherein put(Fqn, Map) doesn't result result in loading data from the cache loader. Result is if the put(...) overwrote a key, the in-memory data in the node has the new value but the old value still exists on disk and node.isDataLoaded() will still return false. When a later request causes JBC to detect that n.isDataLoaded() == false, the old data will be retrieved from the cache loader and will replace the newer correct data. Following test to be added to PassivationTestsBase shows the issue: public void testPutDataMapAfterPassivation() throws Exception { Fqn f = Fqn.fromString("/a"); assert !cache.exists(f); assert !loader.exists(f); Map<Object, Object> input = new HashMap(); input.put("one", "one"); input.put("two", "two"); cache.put(f, input); cache.evict(f); input = new HashMap(); input.put("one", "oneA"); cache.put(f, input); Map data = cache.getRoot().getChild(f).getData(); assertEquals("incorrect # of entries", 2, data.size()); assertEquals("Has key 'one", "oneA", data.get("one")); // FAILS!!! assertEquals("Has key 'two", "two", data.get("two")); } Simple fix is in CacheLoaderInterceptor: change from 'false' to 'true' value of 'allKeys' param passed to loadIfNeeded() by visitPutDataMapCommand(). A more general fix would be to change CacheLoaderInterceptor.loadNode() such that no key/value pair in the map loaded from the cache loader is allowed to override an existing key/value pair in the in-memory node. That could have broader repercussions though, so I intend to fix this the simple way.