[ http://issues.apache.org/jira/browse/JCR-632?page=all ]
Jukka Zitting reopened JCR-632:
-------------------------------
Hmm, actually the change was incorrect. The code after the try-catch-finally
block expects the read lock to still be acquired, so releasing it in the catch
block before throwing an exception was OK, but not in the finally block. This
of course still leaves open the question of what to do with unexpected
RuntimeExceptions.
I'm reverting this change and hope to fix this together with JCR-546.
> VersionManager lock not released in some circumstances
> ------------------------------------------------------
>
> Key: JCR-632
> URL: http://issues.apache.org/jira/browse/JCR-632
> Project: Jackrabbit
> Issue Type: Bug
> Components: versioning
> Affects Versions: 1.0, 1.0.1, 1.1, 0.9
> Reporter: Przemo Pakulski
> Assigned To: Jukka Zitting
> Priority: Critical
> Fix For: 1.1.1
>
> Attachments: JCR-632
>
>
> In some circumstances it is possible that lock is not released in
> VersionManager.checkin method.
> There is following block of code in checkin nethod :
> aquireReadLock();
> try {
> .....
> } catch (IllegalStateException e) {
> releaseReadLock();
> throw new RepositoryException("Unable to start edit operation.");
> }
> Lock release should be in finally block to make sure that lock is released
> when unexpected exception is thrown.
> In our environment we are getting NPE in mentioned block of code, it results
> in persisten lock.
> No versioning operation is possible and our application server is running ot
> of threads (all threads are locked).
--
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
