[
https://issues.apache.org/jira/browse/JCR-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-18:
-----------------------------
Fix Version/s: (was: 1.4)
1.3.2
Merged to the 1.3 branch in revision 581178.
> Multithreading issue with versioning
> ------------------------------------
>
> Key: JCR-18
> URL: https://issues.apache.org/jira/browse/JCR-18
> Project: Jackrabbit
> Issue Type: Bug
> Components: versioning
> Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1, 1.2.2, 1.2.3, 1.3,
> 1.3.1
> Environment: Jackrabbit SVN Rev. 56918
> Reporter: Felix Meschberger
> Assignee: Tobias Bocanegra
> Fix For: 1.3.2
>
>
> In a multithreading environment with two or more threads accessing the same
> version history, inconsistent state may be encountered. Concretely, the first
> thread is currently checking in the node to which the version history is
> attached while the second thread walks this same version history by means of
> a "self-built" iterator, which just accesses the successors of each version
> to get the "next" to visit.
> At a certain point the second point may encounter an ItemNotFoundException
> with a stack trace similar to this:
> javax.jcr.ItemNotFoundException: c9bd405b-dff4-46ef-845c-d98e073e473a
> at
> org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:354)
> at
> org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:230)
> at
> org.apache.jackrabbit.core.SessionImpl.getNodeByUUID(SessionImpl.java:494)
> at
> org.apache.jackrabbit.core.version.VersionImpl.getSuccessors(VersionImpl.java:86)
> ....
> It seems that the first thread has already filled the successor of the
> version, while the node is not yet accessible by the createItemInstance
> method.
> This bug seems to not be enforcible, but it is easily reproducible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
