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

Jukka Zitting resolved JCR-2865.
--------------------------------

       Resolution: Fixed
    Fix Version/s: 2.2.3
         Assignee: Jukka Zitting

Fixed in revision 1065599 and merged to the 2.2 branch in revision 1065610.

The solution I implemented was to take an earlier version of the 
DefaultISMLocking class from before JCR-2699 and adapt it into a 
versioning-only read-write lock class. Besides solving the problem, this change 
helps reduce coupling between the o.a.j.core.version and o.a.j.core.state 
packages.

> a dead lock in DefaultISMLocking
> --------------------------------
>
>                 Key: JCR-2865
>                 URL: https://issues.apache.org/jira/browse/JCR-2865
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-core
>    Affects Versions: 2.2.0
>         Environment: winXP/JDK1.6
>            Reporter: codeparser
>            Assignee: Jukka Zitting
>             Fix For: 2.2.3
>
>         Attachments: trackReader.diff
>
>
> The jackrabbit 2.2 's org.apache.jackrabbit.core.state.DefaultISMLocking has 
> a defect which will cause a dead lock in concurrent use cases.
> The use case is as follows:
> 1.    Thread A apply a read lock, now there is an active reader hold the read 
> lock.
> 2.    Thread B apply a write lock, and then thread B will wait for thread A's 
> reading end. You could see below code snippet from the Jackrabbit source. 
> readerCount is the current active reader.
> writersWaiting++;
> while (writerId != null? !isSameThreadId(writerId, currentId) : readerCount > 
> 0) {
>                                 wait();
> }
> 3.    Thread A apply another read lock, then it will wait too, since there is 
> a writer is waiting.  Then a dead lock happens.
> while (writerId != null? (writerCount > 0 && !isSameThreadId(writerId, 
> currentId)): writersWaiting > 0) {
>                                 wait();
> }
> Since the lock in DefaultISMLocking is global lock, so I think if a thread 
> has already hold a reader lock, it could get the reader lock again. I create 
> a fix with this idea.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to