jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2865) a dead lock in DefaultISMLocking
Date Wed, 02 Feb 2011 16:29:29 GMT

    [ https://issues.apache.org/jira/browse/JCR-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989699#comment-12989699

Thomas Mueller commented on JCR-2865:

You are right, it's not source code duplication, sorry. But it's duplicating logic. The two
classes do almost the same thing, with one small but important difference: DefaultISMLocking
isn't re-entrant for in all cases (is that documented in the source code?), and was the root
cause for this bug and JCR-2753.

> 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
> 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


View raw message