[jboss-jira] [JBoss JIRA] Updated: (JBCACHE-1359) Nodes are not removed during commit if new children have been added to their parents

[Kai Blankenhorn (JIRA)]

     [ 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