[JCR-790] Possible deadlock during concurrent operations on versionable nodes

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: 1.2.1
• Component/s: versioning
• Assignee: Unassigned
• Reporter: Olivier Dony
• Created: 14/Mar/07 11:31
• Updated: 08/Aug/07 06:58
• Resolved: 27/Apr/07 15:50

Description

As discussed on the dev mailing-list:

We are using the Repository Server deployment model for one of our systems, with 3 different web applications using the same jackrabbit 1.2.1 server.
Two of the webapps are read-only frontoffice clients, the third one is a read-write backoffice.

Sometimes the jackrabbit-server enters a deadlock and stops answering requests until it is restarted. A thread dump of the deadlock situation is attached.

From the thread dump analysis provided by Marcel Reutegger (attached too), it appears that two threads are indeed deadlocked while attempting to save() versionable items, after acquiring locks (Workspace SISM/VersionManager) in different orders.
This appears to be the case only because the items being saved are versionable, and because one of them is a new item, which means that the VersionHistory is being created.

We couldn't find an easy way to reproduce this concurrency issue, as it doesn't happen very often, but it takes down our whole system when it does.

Note: if that matters, some of the client applications are using jackrabbit-jcr-rmi-1.1.jar and jackrabbit-jcr-core-1.1.jar to talk to this jackrabbit 1.2.1 server.

Issue Links

• duplicates: JCR-672 Deadlock on concurrent save/checkin operations possible
• relates to: JCR-18 Multithreading issue with versioning