[ 
http://issues.apache.org/jira/browse/JCR-546?page=comments#action_12452086 ] 
            
Jukka Zitting commented on JCR-546:
-----------------------------------

Did you already have time to look at this? It seems correct to me, passes all 
unit tests, and worked fine with an ad-hoc test run with a number of concurrent 
threads doing repeated checkin/checkout operations.

If you're fine with the suggested changes I'd like to have them included 
already in the 1.1.1 release. It's no problem to postpone the fix to 1.2 if you 
prefer to have more time to consider and/or test the change.

> 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: Tobias Bocanegra
>             Fix For: 1.1.1
>
>         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

        

Reply via email to