lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject Re: MultiReader
Date Thu, 01 Apr 2004 18:22:45 GMT
Christoph Goller wrote:
> As far as I understand, MultiReader is a kind of hybrid, trying to achieve
> two different and partly conflicting goals:
> 1) It replaces SegmentsReader, which was and IndexReader accessing several
> SegmentReader in one directory and doing the synchronization (for delete)
> for them using the write lock for the directory and the SegmentInfos with
> the version number to check staleness.
> 2) However, it also combines several IndexReaders that not necessarily
> access Segments of the same directory. In this case synchronization (for
> delete) probably should be done by the IndexReaders themselves.
> Unfortunately, the current implementation of MultiReader does not 
> distinguish these two roles.

You're right.  The locking is now a bit confused.

But, now that I look at it more closely, I'm not sure I like the old 
implementation.  Too much of it is in IndexReader.  IndexReader should 
be kept as abstract as possible.

So, to implement this we might:

1. Remove the writeLock, segmentInfos and doDelete() from IndexReader.

2. Change IndexReader.delete() to be abstract.

3. Rename MultiReader.doDelete() to delete(), so that 
MultiReader.delete() simply delegates to all sub-indexes.

4. Define SegmentReader.delete() to perform version checking and 
locking, then call the protected method doDelete().

5. Define SegmentsReader as a package-private subclass of MultiReader. 
It requires each of its sub-indexes to be a SegmentReader.  It overrides 
the delete() method to check versions, lock the directory, then call 
doDelete() on each sub-index.

What do you think?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message