Thanks simon. In practice my application would have around 100 queries and around 10 add/deletes per minute. Add/deletes should show up immediately. That means that I should always create and close an IndexModifier (and IndexReader for Searching) for each operation, right?
Sure, it cost's a litte performance. But it ensures that 1.) The change is visible immediately 2.) The write.lock (and commit.lock) doesn't remain when the application shut down or crashes On 8/20/06, Simon Willnauer <[EMAIL PROTECTED]> wrote:
On 8/20/06, lude <[EMAIL PROTECTED]> wrote: > Hello, > > when using the new IndexModifier of Lucene 2.0, what would be > the best creation-pattern? > > Should there be one IndexModifier instance in the application (==singelton)? > Could an IndexModifier be opened for a longer time or should it be created > on use and immediately closed? You create an indexmodifier if you want to modify your index. if you wanna commit your data (make it available via index reader / searcher) you close or rather flush your indexmodifier. After closing the modifier you can create a new searcher and all modifications are visible to the searcher / reader. Basically there is one index modifier (or one single modifying instances per index as you must not modify your index with more that one instance of indexreader -writer -modifier). If you use the flush() method you don't need to create a new IndexModifier instance. You can leave your indexmod. open for a long time but without a commit the indexed or deleted documents won't be visible to your searcher / reader) Opening indexmodifiers is a heavy operation which should be used carefully so you can close your modifier every n docs or after a certain idle time. Just be aware that IndexModifier uses IndexReader and IndexWriter internally so if you do a delete after a addDocument the indexwriter will be closed and a new indexreader will be opened. This is also a heavy operation in the meaning of performance. You could keep your deletes until you want to flush your instance of IndexModifier to gain a bit of performance. > > Another issue: > - I create an IndexModifier > - The applicaton crashes > - There exists a write-lock on the index > --> Next time I start the application the IndexModifier couldn't be opened > because of the locks. > > What is the right way to check and delete old write locks? You can use the IndexReader.unlock(Directory dir) method the java doc says: * Caution: this should only be used by failure recovery code, * when it is known that no other process nor thread is in fact * currently accessing this index. To make sure this happens only in recovery mode. best regards Simon > > Thanks > lude > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
