lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lude <lucene.develo...@googlemail.com>
Subject Re: Singleton and IndexModifier
Date Mon, 21 Aug 2006 09:30:31 GMT
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 <simon.willnauer@googlemail.com> wrote:
>
> On 8/20/06, lude <lucene.developer@googlemail.com> 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: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message