Indeed, having to re-open a searcher/reader in order for searches to reflect index modification, can sometimes not best fit with the logic of a certain application.
But see the features made possible with this design: (+) searches do not feel index modifications until desired. (++) no need to synchronize/interfere between searchers and index updates. (+++) stable non-corruptable index without duplicating index data. Doron [EMAIL PROTECTED] wrote on 05/03/2007 11:02:34: > That part is self understood. However as I describe the problem > initially - and the use case is a very practical way of dealing with > documents in real live - they change, we edit them, I don't want to > run a batch re-indexing thing every night... I just wanted done on > the spot. One instance IndexerSeacher it's the way to go I today > agree but because it's reader doesn't detect the changes in the > files because is not being used to do them it's pretty anoying don't > you all thing ? > > -------------- Original message ---------------------- > From: "Erick Erickson" <[EMAIL PROTECTED]> > > <1>. Every time you close/open a reader, you pay a significant penalty > > to warm up caches, etc. You may have to do some tricky dancing > > to coordinate among the sessions to be able to close/reopen > > the reader to allow updates to show up though. > > > > Erick > > > > > > On 3/5/07, Mohammad Norouzi <[EMAIL PROTECTED]> wrote: > > > > > > Hi Erick > > > I am completely confused about this IndexReader. > > > in my case, I have to keep the reader opened because of pagination of the > > > result so I have to had a reader per session. the thing that baffled me is > > > can only one reader service all the session at the same time? > > > > > > I mean > > > 1- having one reader for all sessions and having a Hits for each session. > > > 2- one reader per session. > > > which one is right? > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
