On Fri, May 8, 2009 at 4:27 PM, Jim Murphy <jim.mur...@pobox.com> wrote:
>
> Any pointers to this newer more concurrent behavior in lucene?
At the API level we care about, IndexWriter.commit() instead of close()
Also, we shouldn't have to worry about other parts of the code closing
the writer on us since things like deleteByQuery no longer need to
close the writer to work.
core.getSearcher()... if we don't lock until it's finished, then what
could currently happen is that you could wind up with a newer version
of the index than you thought you might. I think this should be fine
though.
We'd need to think about what type of synchronization may be needed
for postCommit and postOptimize hooks too.
Here's the relevant code:
iwCommit.lock();
try {
log.info("start "+cmd);
if (cmd.optimize) {
openWriter();
writer.optimize(cmd.maxOptimizeSegments);
}
closeWriter();
callPostCommitCallbacks();
if (cmd.optimize) {
callPostOptimizeCallbacks();
}
// 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.
core.getSearcher(true,false,waitSearcher);
-Yonik
http://www.lucidimagination.com
