[ https://issues.apache.org/jira/browse/JCR-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508093 ]
Marcel Reutegger commented on JCR-18: ------------------------------------- Added a test case for this issue: jackrabbit-core\src\test\java\org\apache\jackrabbit\core\ReadVersionsWhileModified.java At revision: 550724 > 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 > Environment: Jackrabbit SVN Rev. 56918 > Reporter: Felix Meschberger > Assignee: Tobias Bocanegra > > 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.