jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Pfister (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-682) AccessManager + CachingHierarchyManager problem
Date Mon, 18 Dec 2006 15:49:23 GMT
    [ 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


View raw message