[
https://issues.apache.org/jira/browse/LUCENE-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847404#action_12847404
]
Michael McCandless commented on LUCENE-2334:
--------------------------------------------
IndexReader.close() is guarding against multiple calls; we can't
remove that (it'd be a back compat break -- I think it's always done
that).
If you separately call .incRef on the IndexReader, you must always
balance that with a matching call to .decRef (best in finally
clause).
> IndexReader.close() should call IndexReader.decRef() unconditionally ??
> -----------------------------------------------------------------------
>
> Key: LUCENE-2334
> URL: https://issues.apache.org/jira/browse/LUCENE-2334
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: 3.0.1
> Reporter: Mike Hanafey
> Priority: Minor
>
> IndexReader.close() is defined:
> {code} /**
> * Closes files associated with this index.
> * Also saves any new deletions to disk.
> * No other methods should be called after this has been called.
> * @throws IOException if there is a low-level IO error
> */
> public final synchronized void close() throws IOException {
> if (!closed) {
> decRef();
> closed = true;
> }
> }
> {code}
> This means that if the refCount is bigger than one, close() does not
> actually close, but it is also true that calling close() again has no effect.
> Why does close() not simply call decRef() unconditionally? This way if
> incRef() is called each time an instance of IndexReader were handed out, if
> close() is called by each recipient when they are done, the last one to call
> close will actually close the index. As written it seems the API is very
> confusing -- the first close() does one thing, but the next close() does
> something different.
> At a minimum the JavaDoc should clarify the behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
