[ 
https://issues.apache.org/jira/browse/LUCENE-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573552#comment-13573552
 ] 

Mark Miller commented on LUCENE-4760:
-------------------------------------

Hey - yeah, the situation is a little ugly and needs to be improved. Please see 
LUCENE-4638 and LUCENE-4246
                
> Weird IndexWriter.close() usage
> -------------------------------
>
>                 Key: LUCENE-4760
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4760
>             Project: Lucene - Core
>          Issue Type: Improvement
>    Affects Versions: 4.1
>            Reporter: i30817
>            Priority: Minor
>
> I'm using IndexWriter on such a way that it can be interrupted, since the 
> streams i'm using to output to file can be interrupted. So far so good, but 
> what i'm finding strange is the (only) way i've found to prevent the file 
> lock being held afterwards.
> Normally i'd do a try / catch / finally block where the finally would close() 
> and handle exceptions from the close. However, IndexWriter "close()" is more 
> like a buffered commit, where many exceptions can occur, so i left it on the 
> main part of the code.
> try{... index.close(); } catch { /*log*/ } finally { 
>                 if (IndexWriter.isLocked(cacheDir)) {
>                     IndexWriter.unlock(cacheDir);
>                 }
> }
> Didn't work. The lock couldn't be unlocked (always) if the stream was 
> interrupted
> So in desperation, i tried to be more literal in my interpretation of the 
> IndexWriter.close() javadoc and tried
>         try {
>             ...
>             indexWriter.close();
>         } catch (IOException ex) {
>             try {
>                 indexWriter.close();
>             } finally {
>                 if (IndexWriter.isLocked(cacheDir)) {
>                     IndexWriter.unlock(cacheDir);
>                 }
>             }
>             throw ex;
>         } finally {
>             ...
>         }
> This worked (the lock was always released if a additional close() was invoked 
> in a situation where the lock would be held before trying to unlock it), but 
> i find it really counter-intuitive, and would wish for at least additional 
> javadoc attention, or a redesign on a major API revision.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to