lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Busch (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-743) IndexReader.reopen()
Date Sat, 20 Oct 2007 09:46:51 GMT

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

Michael Busch commented on LUCENE-743:
--------------------------------------

{quote}
I'm assuming in your example you meant for reader2 and reader3 to also
be SegmentReaders?
{quote}
Yes that's what I meant. Sorry, I didn't make that clear.

{quote}
Also in your example let's insert missing "reader1.close()" as the
very first close? (Else it will never be closed because it's RC never
hits 0).
{quote}
Doesn't what you describe change the semantics of MultiReader.close()?

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().

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.

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.

So do you suggest that a MultiReader should increment the refcounts when it is opened as well
(in the constructor)? I believe we can implement it like this, but as I said it changes the
semantics of MultiReader.close() (and ParallelReader.close() is, I believe, the same). A user
would then have to close subreaders manually.



> 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@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message