lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Mannix <jake.man...@gmail.com>
Subject Re: Realtime search best practices
Date Mon, 12 Oct 2009 19:17:20 GMT
Wait, so according to the javadocs, the IndexReader which you got from
the IndexWriter forwards calls to reopen() back to IndexWriter.getReader(),
which means that if the user has a NRT reader, and the user keeps calling
reopen() on it, they're getting uncommitted changes as well, while if they
call reopen() on a regular IndexReader, they do not?

How does this play nicely with the transactional semantics given by
commit()?

On Mon, Oct 12, 2009 at 12:11 PM, Michael McCandless <
lucene@mikemccandless.com> wrote:

> Just to clarify: IndexWriter.newReader returns a reader that searches
> uncommitted changes as well.  Ie, you need not call IndexWriter.commit
> to make the changes visible.
>
> However, if you're opening a reader the "normal" way
> (IndexReader.open) then it is necessary to first call
> IndexWriter.commit.
>
> Mike
>
> On Mon, Oct 12, 2009 at 5:24 AM, melix <cedric.champeau@lingway.com>
> wrote:
> >
> > Hi,
> >
> > I'm going to replace an old reader/writer synchronization mechanism we
> had
> > implemented with the new near realtime search facilities in Lucene 2.9.
> > However, it's still a bit unclear on how to efficiently do it.
> >
> > Is the following implementation the good way to do achieve it ? The
> context
> > is concurrent read/writes on an index :
> >
> > 1. create a Directory instance
> > 2. create a writer on this directory
> > 3. on each write request, add document to the writer
> > 4. on each read request,
> >  a. use writer.getReader() to obtain an up-to-date reader
> >  b. create an IndexSearcher with that reader
> >  c. perform Query
> >  d. close IndexSearcher
> > 5. on application close
> >  a. close writer
> >  b. close directory
> >
> > While this seems to be ok, I'm really wondering about the performance of
> > opening a searcher for each request. I could introduce some kind of delay
> > and cache a searcher for some seconds, but I'm not sure it's the best
> thing
> > to do.
> >
> > Thanks,
> >
> > Cedric
> >
> >
> > --
> > View this message in context:
> http://www.nabble.com/Realtime-search-best-practices-tp25852756p25852756.html
> > Sent from the Lucene - Java Users mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> 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