There is something I've witnessed though which one should be aware
of when sharing an IndexWriter and doing multiple writes on multiple threads
with the desire to commit or rollback a distinct units of work on those
threads.
The typical pattern of use is to have one IndexWriter open and call
GetReader on it to get your readers. This also means that you will add and
update documents through that one writer.
If you are trying to update two separate documents at the same time
and need to commit one and roll back the other, you have to synchronize
access to the IndexWriter, as the PrepareCommit/Commit/Rollback is across
the entire index and all the documents that have been added/updated since
the last call to Commit or Rollback.
- Nick
-----Original Message-----
From: Digy [mailto:[email protected]]
Sent: Thursday, July 22, 2010 2:17 PM
To: [email protected]; [email protected]
Subject: RE: Consistency and Performance
Hi Li,
Lucene.Net is thread(+process) safe. So you don't have to implement your own
concurrency control.
You can create a single IndexWriter, make updates on it(even with many
threads) and acquire an up-to-date IndexReader (by IndexWriter's GetReader
method) whenever a search request arrives without thinking on "concurrency
control"
DIGY.
-----Original Message-----
From: Li Bing [mailto:[email protected]]
Sent: Thursday, July 22, 2010 9:03 PM
To: [email protected]
Subject: Consistency and Performance
Dear all,
I asked the similar question one week ago. But I have not got any answers
until now. I just clarifies my questions as follows.
When the size of an index is large and it is being updated, should the
operation of searching be suspended until the updating is done? In my
system, since I use .NET concurrency control to manage the consistency, the
performance becomes lower for the above issue.
How does Lucene.NET handle this inside? If I remove my concurrency control,
the performance will not be affected by updating?
Thanks,
Bing
