ReentrantReadWriteLock in DUH2
I'm sorry if this is a stupid question but I'm curious why DUH2 uses ReentrantReadWriteLock. What is the purpose of it? Thank you, Koji
Re: ReentrantReadWriteLock in DUH2
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. - Mark On Nov 6, 2008, at 6:24 AM, Koji Sekiguchi [EMAIL PROTECTED] wrote: I'm sorry if this is a stupid question but I'm curious why DUH2 uses ReentrantReadWriteLock. What is the purpose of it? Thank you, Koji
Re: ReentrantReadWriteLock in DUH2
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/. Koji
Re: ReentrantReadWriteLock in DUH2
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
