[ http://issues.apache.org/jira/browse/JCR-18?page=all ]
Jukka Zitting updated JCR-18:
-----------------------------
Version: 0.9
1.0
> Multithreading issue with versioning
> ------------------------------------
>
> Key: JCR-18
> URL: http://issues.apache.org/jira/browse/JCR-18
> Project: Jackrabbit
> Type: Bug
> Components: versioning
> Versions: 0.9, 1.0
> Environment: Jackrabbit SVN Rev. 56918
> Reporter: Felix Meschberger
> Assignee: Tobias Bocanegra
> Fix For: 1.1
>
> 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.
-
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
