[
http://jira.jboss.com/jira/browse/JBCACHE-1359?page=all ]
Kai Blankenhorn updated JBCACHE-1359:
-------------------------------------
Attachment: TreeCache_JBCACHE-1359.diff
The patch I attached changes the TreeCache.realRemove so it does not skip nodes not marked
for removal. Instead it recurses into their children.
This adds complexity to the commit phase, as major parts of the cache will be visited if
only a small part has been removed.
Another solution could be to add the marked nodes to the TransactionEntry's list of
removed nodes when readding a parent: When /a is readded (unmarked), check if it has
marked children and call TransactionEntry.addRemovedNode.
Nodes are not removed during commit if new children have been added
to their parents
------------------------------------------------------------------------------------
Key: JBCACHE-1359
URL:
http://jira.jboss.com/jira/browse/JBCACHE-1359
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 1.4.1.SP9
Reporter: Kai Blankenhorn
Assigned To: Manik Surtani
Attachments: TreeCache_JBCACHE-1359.diff
Say we have a cache instance called "cache" that is configured to use a custom
CacheLoader that always returns "value from CacheLoader". Now we call:
cache.put("/a/b/c", "key", "cachedValue");
cache.remove(Fqn.ROOT);
cache.put("/a/B/c", "key", "cachedValue");
commitTx();
String val = (String) cache.get("/a/b/c", "key");
assertEquals("value from CacheLoader", val);
The result will be null instead of "value from CacheLoader".
The problem is that the parent nodes (for instance, "/a/b") are marked for
removal. In the same transaction after removing "/a/b", "/a" is
readded and thus unmarked. When the transaction is committed, "/a" is about to
be realRemove()d. But this method skips the node and its children, as it is no longer
marked for removal. This way "/a/b" is never removed and stays marked for
removal.
When reading "/a/b/c", the iteration over the fqn elements in
TreeCache.findInternal() skips all nodes marked for removal, never reaching the requested
node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira