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

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

Hi Mike,

I'm not sure if I fully understand your comment. Consider the following (quite 
constructed) example:

{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
... // modify index1
IndexReader reader2 = reader1.reopen();
// reader2 is a new instance that shares resources with reader1
... // modify index1
IndexReader reader3 = reader2.reopen();
// reader3 is a new instance that shares resources with reader1 and reader2
{code}

Now the user closes the readers in this order:
# multiReader1.close();
# multiReader2.close();
# reader2.close();
# reader3.close();

reader1 should be marked as closed after 2., right? Because 
multiReader1.close() and multiReader2.close() have to decrement reader1's 
refcount. But the underlying files have to remain open until after 4., because 
reader2 and reader3 use reader1's resources.

So don't we need 2 refcount values in reader1? One that tells us when the 
reader itself can be marked as closed, and one that tells when the resources 
can be closed? Then multiReader1 and multiReader2 would decrement the first 
refCount, whereas reader2 and reader3 both have to "know" reader1, so that they 
can decrement the second refcount.

I hope I'm just completely confused now and someone tells me that the whole 
thing is much simpler :-)



> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to