jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-18) Multithreading issue with versioning
Date Fri, 19 Nov 2004 14:20:28 GMT
     [ http://nagoya.apache.org/jira/browse/JCR-18?page=comments#action_55681 ]
Felix Meschberger commented on JCR-18:

Sorry, to say this, but the issue is only partly solved. While it occurrs less frequently
than before it still occurrs.

Again, I get the same exception at the same place at a moment where another thread is currently
checkin, which modifies the successors of while the referred-to node is not (yet?) accessible.

Here is the stack of the other thread:
   Thread [--some undisclosed name--] (Suspended)
      BDbPersistenceManager.load(NodeReferences) line: 398
      ReferenceManager.get(NodeId) line: 62
      PropertyImpl(ItemImpl).checkReferences(Iterator, Iterator, ReferenceManager) line: 635
      PropertyImpl(ItemImpl).save() line: 1132
      NodeImpl.checkin() line: 2004

> Multithreading issue with versioning
> ------------------------------------
>          Key: JCR-18
>          URL: http://nagoya.apache.org/jira/browse/JCR-18
>      Project: Jackrabbit
>         Type: Bug
>  Environment: Jackrabbit SVN Rev. 56918
>     Reporter: Felix Meschberger
>     Assignee: Tobias Strasser

> 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:
If you want more information on JIRA, or have a bug to report see:

View raw message