[
https://issues.apache.org/jira/browse/JCR-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989707#comment-12989707
]
Jukka Zitting commented on JCR-2865:
------------------------------------
That crucial difference (documented in the ISMLocking javadocs) is what makes
the design of these two classes so different and what enables the performance
optimizations implemented in JCR-2699. By similar logic also the ArrayList and
LinkedList classes in java.util are duplicates.
> 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
