On 6-Nov-08, at 7:48 AM, Koji Sekiguchi wrote:
> So that multiple threads can efficiently access the writer, but
only one thread at a time does a commit.
> Adding docs with the writer is the 'read' and committing is the
write. If I remember correctly.
You remember correctly, Mark. Because of the lock, <add/> is blocked
during <optimize/>, even if ConcurrentMergeScheduler is used, right?
I'd like to know why <add/> should be blocked during <optimize/>.
The core reason is laid out in the comment:
// open a new searcher in the sync block to avoid opening it
// after a deleteByQuery changed the index, or in between deletes
// and adds of another commit being done.
We want to open a searcher than corresponds exactly to the commit
point (remember, an optimize is first and foremost a commit).
I don't see why there couldn't be an optimize command that doesn't
commit, if that is desired.
-Mike
