[ http://issues.apache.org/jira/browse/JCR-632?page=all ]
Jukka Zitting updated JCR-632: ------------------------------ Component/s: versioning Fix Version/s: 1.1.1 Affects Version/s: 0.9 1.0 1.0.1 1.1 Assignee: Jukka Zitting You're right, the release should be in the finally block. > 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