[ http://issues.apache.org/jira/browse/JCR-546?page=all ]
Jukka Zitting updated JCR-546:
------------------------------
Affects Version/s: 1.1.1
> 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, 1.1.1
> 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
