lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <>
Subject Re: Concurrent merge
Date Thu, 22 Feb 2007 03:31:21 GMT
On 2/21/07, Doron Cohen <> wrote:
> > > The downside is another complexity increase though.
> I think complexity can be divided in two:
> (1) more complex synchronization and data-manipulation/accounting
> (2) multi-threading.
> The multi-threading becoming part of and responsibility of Lucne
> seems quite a change to me. Lucene's being single threaded is a
> simplifying factor, an advantage to my opinion.

I definitely agree with that point.  MultiSearcher spins up threads, but it's
not as core as IndexWriter.

> So how about, alternatively, (perhaps optionally, probably in a
> subclass) just reducing the synchronization level of IndexWriter,
> so one could call addDocument, deleteDocument, optimize() etc.
> in more than one thread, in parallel.
> The critical sections would be similar to the proposal below, and
> delicate synchronization details need to be looked after. It is
> in fact possible that synchronization wise this is more challenging
> then the proposal when Lucene launches the threads, because there
> can be more than two threads.
> But this way Lucene itself remains single threaded. It is the
> application decision/responsibility to launch and manage these
> threads.
> Just a thought.

Yeah, I thought about things like this as well... including separating
the analysis
from adding the doc, but whatever I came up with it tended to
complicate the job of the user, esp if deletes are thrown in.


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

View raw message