my only caution is that as your index grows, the close/open of your readers may take more time than you are willing to spend. Not that I'm recommending against it as I don't know the details, but it's something to keep an eye on. In my experience, "immediately available" may really mean "available after 10 minutes", so you can think about allowing a little latency to improve query speed if that becomes an issue.....
Best Erick On 8/21/06, lude <[EMAIL PROTECTED]> wrote:
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] > >
