[ http://issues.apache.org/jira/browse/JCR-682?page=comments#action_12459386 ] Dominique Pfister commented on JCR-682: ---------------------------------------
Thanks to your test case, I could easily reproduce the issue: it happens when transient items are reordered. The CachingHierarchyManager uses the method NodeState.getReorderedChildNodeEntries() to retrieve the set of reordered items, but this returns only changes between some state and its overlayed (i.e. persistent) state. Your test case performs the following operations in pseudo code: - addNode -> N1 - addNode -> N2 - addNode -> N3 - orderBefore(N3, N2) which leaves the CachingHierarchyManager with an empty reordered list since the nodes have not yet been persisted. The CachingHierarchyManager should better evict its associated cache entry, if it detects a purely transient reorder. > AccessManager + CachingHierarchyManager problem > ----------------------------------------------- > > Key: JCR-682 > URL: http://issues.apache.org/jira/browse/JCR-682 > Project: Jackrabbit > Issue Type: Bug > Components: core > Affects Versions: 1.1.1 > Reporter: Roland Kofler > Attachments: CachingHierarchManagerTest.zip > > > The problem we have is the implementation of the CachingHierarchyManager, > to which the SimpleAccessManager holds a reference. > Let's consider following example: > i add 3 subnodes (a,b,c) to a node and after that i reorder b and c .. > so i have a,c,b. in the process of reordering (using the function > orderBefore of javax.jcr.Node) our AccessManager is called several times to > check the permissions of the nodes. In this AccessManager we use some > functions of the CachingHierarchyManager, f.ex. > Path itemPath = hierMgr.getPath(id); > return itemPath.denotesRoot(); > or > Path itemPath = hierMgr.getPath(itemId); > Path parentPath = itemPath.getAncestor(1); > return hierMgr.resolvePath(parentPath); > the problem is, that when calling the methods of the > CachingHierarchyManager the nodes i ask for will be cached in the idCache in > a wrong state (i. e.: before actually reordering the elements). > so if i want f.ex. delete the node b after reordering, the node will > be looked up in the idCache. in the cache the index of node b is still 2 > (actually it should be 3) and so the wrong node will be deleted! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
