[
https://issues.apache.org/jira/browse/JCR-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697613#comment-13697613
]
Marcel Reutegger commented on JCR-3617:
---------------------------------------
Added (disabled) test in revision 1498840.
> Inconsistent CachingHierarchyManager under concurrent access
> ------------------------------------------------------------
>
> Key: JCR-3617
> URL: https://issues.apache.org/jira/browse/JCR-3617
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.2, 2.4, 2.6
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Priority: Minor
>
> This is a bit difficult to reproduce and so far I'm not able to provide a
> standalone test case for this issue. However, the following happens on the
> application level: a sub-tree is replaced with a modified version of the
> sub-tree while event listeners track those changes and try to get items for
> the given event paths. In some cases the repository throws an exception when
> Session.getItem() is called similar to what was reported in JCR-3368.
> It is important to note that the replaced subtree has some special
> characteristics. The root node of the sub-tree is re-created with the same
> UUID, while descendant nodes may be replaced with different UUIDs, but still
> have the same name.
> There seems to be a short time window where the modifying Session saves this
> kind of change, which gets propagated up to the ItemState layers and into the
> CachingHierarchyManager and the listening Session (owning the
> CachingHierarchyManager) access modified items at the same time through the
> CachingHierarchyManager. In some cases this seems to create an inconsistent
> state in the CachingHierarchyManager where a path is mapped to the old UUID
> (and vice versa) even though the replace already happened.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
