[
http://jira.jboss.com/jira/browse/JBCACHE-1296?page=comments#action_12401407 ]
Manik Surtani commented on JBCACHE-1296:
----------------------------------------
So in the pessimistic case this was actually a pretty simple bug - when marking a node as
deleted, the PLI wasn't doing this recursively for children as well. This worked if
all there was was a deletion since in commit the marked node is really removed and
children are removed as well. When followed by a create, however, the node recreated (/a
in your test) will have it's deleted flag reversed. But since the deleted flag never
was applied to children, they don't get removed as expected.
Simple fix, just made that flag recursive when a node is removed.
Deleting and readding parent node in tx causes deleted children to
survive
--------------------------------------------------------------------------
Key: JBCACHE-1296
URL:
http://jira.jboss.com/jira/browse/JBCACHE-1296
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 2.1.0.CR4
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Priority: Critical
Fix For: 2.1.0.GA
If a parent node is deleted in a tx, and then in the same tx the parent node is
reestablished, pre-existing children of the parent will remain in the cache after the tx
commits. They should not.
See test org.jboss.cache.api.DeletedChildResurrectionTest for examples. There are 4
tests, 2 each with pessimistic and optimistic locking. One variant reestablishes the
parent by simple re-adding it. Another indirectly reestablishes the parent by adding a
new child. All fail, but not always in the same way.
--
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