[Created] (JCR-3597) Dead lock when using LockManager session scoped locks on nodes
Davide Maestroni (JIRA <jira <at> apache.org>
2013-05-17 13:43:16 GMT
Davide Maestroni created JCR-3597:
-------------------------------------
Summary: Dead lock when using LockManager session scoped locks on nodes
Key: JCR-3597
URL: https://issues.apache.org/jira/browse/JCR-3597
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.6.1
Environment: Sling + Jackrabbit
Reporter: Davide Maestroni
Priority: Blocker
Attachments: thread_dump.txt
I have a repository created using Jackrabbit and accessed through HTTP APIs via Sling. I use the
LockManager class to create locks on nodes before adding new children and updating properties. When
testing the speed of the system I ran across an issue when using different threads to add child nodes to
different parent nodes: a dead lock happens quite consistently when one thread is logging out from a JCR
session and another one is saving its own session (I'll attach the thread dump to the JIRA issue).
So I started inspecting the source code, trying to understand what the problem was, and I think I located the
problem. Basically it all happens when calling the SharedItemStateManager.beginUpdate() method: one
thread, inside the Update.begin(), acquires the synchronized lock on the LocalItemStateManager
instance and wait for the ISMLocking lock to be released (Thread t <at> 295 in the logs); while the other, which
owns the ISMLocking lock, inside the Update.end() triggers an event which in turn try to synchronize with
the LocalItemStateManager instance (Thread t <at> 293 in the logs).
I noticed that the LocalItemStateManager implementation employs synchronized blocks only in two
instances: one in the edit() method to synchronize the whole function, and one in the getItemState()
method to synchronize the access to the cache object. Both are quite odd since: the edit() is the only
synchronized method and there are several other places in which editMode and changeLog are modified, so
(Continue reading)