jira at apache
Oct 20, 2007, 3:45 AM
Post #36 of 71
(759 views)
Permalink
|
|
[jira] Commented: (LUCENE-743) IndexReader.reopen()
[In reply to]
|
|
[ https://issues.apache.org/jira/browse/LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536418 ]
Michael McCandless commented on LUCENE-743:
-------------------------------------------
{quote}
If you do:
{code:java}
IndexReader reader1 = IndexReader.open(index1);
IndexReader multiReader1 = new MultiReader(new IndexReader[] {reader1, IndexReader.open(index2)});
multiReader1.close();
{code}
then today multiReader1.close() also closes reader1. That's why I consciously omitted reader1.close().
{quote}
Ahh, I missed that MultiReader is allowed to close all readers that
were passed into it, when it is closed. OK, let's leave
reader1.close() out of the example.
It's somewhat "aggressive" of MultiReader/ParallelReader to do that?
If you go and use those same sub-readers in other MultiReaders then
they closing of the first MultiReader will then break the other ones?
I think we are forced to keep this semantics, for backwards
compatibility. But I don't really think MultiReader/ParallelReader
should actually be this aggressive. Maybe in the future we can add
ctors for MultiReader/ParallelReader that accept a "doClose" boolean
to turn this off.
Anyway, it's simple to preserve this semantics with reference
counting. It just means that IndexReader / MultiReader do not incref
the readers they receive, and, when they are done with those readers,
they must call their close(), not decref. Ie they "borrow the
reference" that was passed in, rather than incref'ing their own
reference, to the child readers.
With that change, plus the change below, your example works fine.
{quote}
Consequently, if you do
{code:java}
IndexReader reader1 = IndexReader.open(index1);
IndexReader multiReader1 = new MultiReader(new IndexReader[] {reader1, IndexReader.open(index2)});
IndexReader multiReader2 = new MultiReader(new IndexReader[] {reader1, IndexReader.open(index3)});
multiReader1.close();
{code}
then multiReader2 is not usable anymore, because multiReader1.close() closes reader1. But that can be explicitly avoided by the user because it's known that multiReader1 and multiReader2 share the same reader.
{quote}
This is why I don't like the semantics we have today -- I don't think
it's right that the multiReader1.close() breaks multiReader2.
{quote}
Now, with the reopen() code:
{code:java}
IndexReader reader1 = IndexReader.open(index1); // optimized index, reader1 is a SegmentReader
IndexReader multiReader1 = new MultiReader(new IndexReader[] {reader1, IndexReader.open(index2)});
... // modify index2
IndexReader multiReader2 = multiReader1.reopen();
// only index2 changed, so multiReader2 uses reader1 and has to increment the refcount of reader1
{code}
The user gets a new reader instance from multiReader.reopen(), but can't tell which of the subreaders has been reopened and which are shared. That's why multiReader1.close() should not close reader1 in this case and we need refcounting in order to make this work.
{quote}
Both of these cases are easy to fix with reference counting: we just
have to change ensureOpen() to assert that RC > 0 instead of
closed==false. Ie, a reader may still be used as long as its RC is
still non-zero.
> IndexReader.reopen()
> --------------------
>
> Key: LUCENE-743
> URL: https://issues.apache.org/jira/browse/LUCENE-743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Otis Gospodnetic
> Assignee: Michael Busch
> Priority: Minor
> Fix For: 2.3
>
> Attachments: IndexReaderUtils.java, lucene-743-take2.patch, lucene-743.patch, lucene-743.patch, lucene-743.patch, MyMultiReader.java, MySegmentReader.java, varient-no-isCloneSupported.BROKEN.patch
>
>
> This is Robert Engels' implementation of IndexReader.reopen() functionality, as a set of 3 new classes (this was easier for him to implement, but should probably be folded into the core, if this looks good).
--
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: java-dev-unsubscribe [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene
|
