[
https://issues.apache.org/jira/browse/JCR-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988734#comment-12988734
]
Jukka Zitting commented on JCR-2865:
------------------------------------
> Why we can not modify the DefaultISMLocking class
It's a very performance-critical piece of code in highly concurrent and fully
cached use cases (i.e. a typical web server). See JCR-2699 for the work I did
to streamline the synchronized acquireReadLock() method as much as possible.
Currently the method doesn't allocate any new memory or make any structural
changes to any data structures, and I'd like to keep it that way until we can
come up with a way to avoid synchronization.
The improved logic in DefaultISMLocking was based on a rather thorough review
of the concurrency requirements of the ISMLocking interface. Unfortunately I
failed to take into account the fact that the DefaultISMLocking class is also
being used directly by the version manager outside the ISMLocking contract.
This and the other referenced issues are a result of this.
ISM and version locking are really two separate cases with somewhat different
requirements, which is why I don't think it's a good idea to use a single class
for both cases. I'll go forward and implement the idea I suggested earlier
about splitting the class into two different copies.
> 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
> 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
