Guys, please - you're not new at this... this is what JavaDoc is for: /** * Returns a readonly reader containing all * current updates. Flush is called automatically. This * provides "near real-time" searching, in that changes * made during an IndexWriter session can be made * available for searching without closing the writer. * * <p>It's near real-time because there is no hard * guarantee on how quickly you can get a new reader after * making changes with IndexWriter. You'll have to * experiment in your situation to determine if it's * fast enough. As this is a new and experimental * feature, please report back on your findings so we can * learn, improve and iterate.</p> * * <p>The resulting reader supports {...@link * IndexReader#reopen}, but that call will simply forward * back to this method (though this may change in the * future).</p> * * <p>The very first time this method is called, this * writer instance will make every effort to pool the * readers that it opens for doing merges, applying * deletes, etc. This means additional resources (RAM, * file descriptors, CPU time) will be consumed.</p> * * <p>For lower latency on reopening a reader, you should * call {...@link #setMergedSegmentWarmer} to * pre-warm a newly merged segment before it's committed * to the index. This is important for minimizing * index-to-search delay after a large merge. </p> * * <p>If an addIndexes* call is running in another thread, * then this reader will only search those segments from * the foreign index that have been successfully copied * over, so far</p>. * * <p><b>NOTE</b>: Once the writer is closed, any * outstanding readers may continue to be used. However, * if you attempt to reopen any of those readers, you'll * hit an {...@link AlreadyClosedException}.</p> * * <p><b>NOTE:</b> This API is experimental and might * change in incompatible ways in the next release.</p> * * @return IndexReader that covers entire index plus all * changes made so far by this IndexWriter instance * * @throws IOException */ public IndexReader getReader() throws IOException {
-Yonik http://www.lucidimagination.com On Mon, Oct 12, 2009 at 4:18 PM, John Wang <john.w...@gmail.com> wrote: > Oh, that is really good to know! > Is this deterministic? e.g. as long as writer.addDocument() is called, next > getReader reflects the change? Does it work with deletes? e.g. > writer.deleteDocuments()? > Thanks Mike for clarifying! > > -John > > 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org