[ 
https://issues.apache.org/jira/browse/JCR-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-2753:
-------------------------------

    Attachment: JCR-2753.patch

We discussed this with Thomas, and it turns out that synchronous observation 
listeners do need to reacquire ISM read locks after the SISM.Update.end() has 
downgraded the write lock it was holding. One way to solve this problem without 
having to maintain a set of current holders of the read lock is to simply 
remove the writer preference in the locking strategy, i.e. allow readers to 
acquire the lock even when there are pending writers waiting for the lock. 
Another solution, implemented in the attached patch (against the "new" 
DefaultISMLocking implementation of revision 99541), is to retain the writer 
thread identifier in a downgraded lock, so a downgraded write lock would still 
allow related threads to reacquire the lock even when there are other writers 
waiting.

> Deadlock in DefaultISMLocking
> -----------------------------
>
>                 Key: JCR-2753
>                 URL: https://issues.apache.org/jira/browse/JCR-2753
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>            Reporter: Thomas Mueller
>            Assignee: Thomas Mueller
>             Fix For: 2.2.0
>
>         Attachments: JCR-2753.patch
>
>
> There seems to be a bug in DefaultISMLocking which was detected as part of 
> JCR-2746.
> 1) The main thread gets a read lock.
> 2) The ObservationManager thread tries to lock for writing, which is blocked 
> because there is still a read lock.
> 3) Then the main thread tries to get a second read lock, which is blocked 
> because there is a waiting write lock.
> The bug was introduced as part of JCR-2089 (Use java.util.concurrent), 
> revisions 995411 and 995412. I think the safe solution is to revert those to 
> commits, and add a test case. If the DefaultISMLocking is changed later on, 
> more test cases are required. An efficient solution is relatively complicated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to