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] Reopened: (JCR-632) VersionManager lock not released in some circumstances
Date Thu, 16 Nov 2006 11:27:40 GMT
     [ 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
> 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
> 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


View raw message