Issue Details (XML | Word | Printable)

Key: JCR-18
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Tobias Bocanegra
Reporter: Felix Meschberger
Votes: 2
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Jackrabbit Content Repository

Multithreading issue with versioning

Created: 10/Nov/04 09:27 PM   Updated: 08/Oct/07 10:47 AM
Return to search
Component/s: versioning
Affects Version/s: 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
Fix Version/s: 1.3.3

Time Tracking:
Not Specified

Environment: Jackrabbit SVN Rev. 56918
Issue Links:
Reference

Resolution Date: 26/Jun/07 08:01 AM


 Description  « Hide
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.

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Tobias Bocanegra added a comment - 11/Nov/04 02:44 PM
i must admit that i took no care about multihtreading until now. but of course i will do it now.

Tobias Bocanegra added a comment - 17/Nov/04 10:02 AM
fixed at revision 76106

Felix Meschberger added a comment - 19/Nov/04 02:19 PM
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
      ...

Tobias Bocanegra added a comment - 19/Nov/04 02:46 PM
will investigage

Felix Meschberger added a comment - 19/Nov/04 02:53 PM
Sorry again: My previous remark on "less frequently" is completely wrong. It occurrs as often as before :-(

Jukka Zitting added a comment - 31/May/06 03:36 PM
Fixing issue JCR-443 seems to have fixed a few other concurrent versioning problems. Is this issue also fixed by JCR-443?

Marcel Reutegger added a comment - 26/Jun/07 07:59 AM
Added a test case for this issue:

jackrabbit-core\src\test\java\org\apache\jackrabbit\core\ReadVersionsWhileModified.java

At revision: 550724

Marcel Reutegger added a comment - 26/Jun/07 08:01 AM
The test runs without deadlock or errors. I will therefore set this issue to fixed.

Jukka Zitting added a comment - 02/Oct/07 10:03 AM
Merged to the 1.3 branch in revision 581178.