jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (JCR-546) Deadlock during checkin
Date Thu, 23 Nov 2006 19:19:04 GMT
     [ http://issues.apache.org/jira/browse/JCR-546?page=all ]

Jukka Zitting resolved JCR-546.

    Fix Version/s: 1.2
                       (was: 1.1.1)
       Resolution: Fixed
         Assignee: Jukka Zitting  (was: Tobias Bocanegra)

Applied the proposed changes in a sequence of commits to make selective reverting easier if
a problem is detected. The commits are:

    revision 478634: s/aquire/acquire/
    revision 478641: Consistently use the try-finally pattern for acquiring locks
    revision 478644: Introduced the WriteOperation helper class to hide the handling of the
StateManager and the write lock.
    revision 478645: Guard the entire checkin() method with the write lock

Only the last change should introduce functional changes (extended use of the write lock),
the other changes are pure refactorings to clarify the code structure.

I'll leave these changes in the trunk for now and not include them in the 1.1.1 release since
I'm not 100% certain that I haven't missed some subtle concurrency issues.

> Deadlock during checkin
> -----------------------
>                 Key: JCR-546
>                 URL: http://issues.apache.org/jira/browse/JCR-546
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: versioning
>    Affects Versions: 1.0, 1.0.1, 1.1, 0.9
>         Environment: WinXP Jackrabbit r431916
>            Reporter: Rod Mackenzie
>         Assigned To: Jukka Zitting
>             Fix For: 1.2
>         Attachments: JCR-546.patch
> Under a load of 3 threads performing checkin and restore operations it's possible for
all to become deadlocked in AbstractVersionManager.checkin(). This method attempts to upgrade
a read lock to a write lock with the following code
>     aquireReadLock();
>     ....
>     try {
>         aquireWriteLock();
>         releaseReadLock();
>         ...
> If 2 or more threads acquire the read lock then neither can acquire the write lock resulting
in the deadlock, and after that any other thread that calls this method will block waiting
for the write lock. The release of the read lock needs to be done before acquiring the write
lock, this is documented Concurrent library javadoc.
> There is another area where there is an attempt to upgrade a read lock to write lock,
RepositoryImpl.WorkspaceInfo.disposeIfIdle() acquires a read lock and calls dispose() which
then acquires a write lock, this maybe ok, as I assume there is only 1 thread that will attempt
to dispose of idle workspaces.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message