> From what you said, I'm thinking of switching to IndexModifier. Yes, IndexModifier would synchronize add/delete. One should notice the performance comment in IndexModifier http://lucene.apache.org/java/docs/api/org/apache/lucene/index/IndexModifier.html - "While you can freely mix calls to add() and delete() using this class, you should batch you calls for best performance. For example, if you want to update 20 documents, you should first delete all those documents, then add all the new documents."
> Before that, > I have a few more questions: > 1. without using an exclusive lock, is there anyway to new a IndexModifier > or IndexWritter while IndexReaders are serving search queries? or do I have > to new a IndexWriiter when system starts and keep it open all the time? It is possible to open an IndexWriter while a searcher is open. For search to "feel" the changes made by the writer, a new searcher should be opened (after the writer is closed or after it writes from memory to disk. With IndexModifier, the flush() method can be used.) > 2. When adding a new document, and calling optimize(), do I have to close > the readers/searchers? No need to close searchers. "Lucene in Action" book, chapter 2.9 explains this much better than I can, and draws a table of "what can run with what else". > 3. In my case, updating non-idexed fields happens a lot, can you explain the > side data store in more detail? I'm not sure with this approach. Do you mean > creating a separate database and stores lucene's ids? Yes, a separate store, with mapping from ID to mutable fields of the document with this ID. When adding a doc to Lucene, a stored field would be added to contain the ID of the added doc. At search time, the ID would be retrieved for that doc, and can be used to fetch the mutable fields from the separate store. But I think it is better to start with the simpler approach - updating documents in Lucene - and turn to something more complex only if there are unacceptable performance issues due to updating these documents fields. Regards, Doron --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
