On 2/21/07, Doron Cohen <[EMAIL PROTECTED]> 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.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
