lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Goller <>
Subject Re: MultiReader
Date Fri, 16 Apr 2004 09:13:33 GMT
Here are some explanations concerning my latest commit on
restructuring IndexReader/SegmentReader/MultiReader/FilterIndexReader

*) The reason for this restructuring was that directory locking
in case of delete, undelete, and setNorm was a bit confused
especially with MultiReader.

*) After some deep brain racking I decided to keep the old design
and not to take Dougs proposal. All synchronization (directory
locking in case of delete, undeleteAll, and setNorm) is now down
in the abstract IndexReader class. However, not all IndexReaders
necessarily do directory locking. Only those that are directory
owners. This means that depending on the constructor used to construct
an IndexReader (or one of its subclasses) it does directory locking or
it does not. A SegmentReader that owns its directory (if it is the only
segment in the directory) does directory locking, if the SegmentReader
is part of a MultiReader that owns the directory, directory locking is
done by the Multireader, and not by the individual SegmentReaders.
This is the case for IndexReaders acquired from
There is also a public constructor for MultiReader, that takes an
array of IndexReaders. In this case Multireader does no directory
locking. The situation is similar for FilterIndexReader which also
leaves locking to its base reader.

*) The API has not changed, however the bahavior of some API
methods has changed slightly. The reason for this is that
setNorm and undeletAll do change the index and therefore need
a write lock on the directory. This was a so far undiscovered bug.
The biggest differenc is that calling undeleteAll has only an effect
on the the Readers. The changes are not written to the index before
IndexReader.close is called. This is bahavior we are used to in case
of delete.

*) Up till now IndexReader.close() always closed the directory, even
if the IndexReader was acquired with dir).
This means that dir became unusable after opening and closing an
Indexreader on it. I think this is not the behavior expected by users.
I changed IndexReader so that IndexReader.close() no only closes its
directory if IndexReader was opened with or If this change is accepted, we sould change
IndexWriter in the same way.

*) This commit also changes some unit tests. TestIndexReader
now fails with the old implementation since in the old implementation
Multireader does no directory locking.


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

View raw message