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 < luc...@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.champ...@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-unsubscr...@lucene.apache.org > > For additional commands, e-mail: java-user-h...@lucene.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > >
