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