> As I understand it, the user won't see any changes to the index until a new Searcher is created.
Correct. > How much memory will caching the searcher cost? Are there other tradeoff's I need to consider? If you're updating the index frequently (every N seconds) and the searcher/reader is closed reasonably quickly (under 5 minutes) then it should work. There will be files left around a little longer than usual, which depends on their size and your disk capacity (usually won't matter). With things like LUCENE-1313 coming up, the incoming updates wouldn't be creating small segments on disk, meaning only larger segments are written to disk and keeping a searcher open (while eating more RAM, under the specified limit) will happen, extra largish disk files hanging around won't happen. When doing distributed search in something like SOLR I wonder how this solution would work. Maybe it would simply use HTTP sessions ids as well. On Fri, Jun 19, 2009 at 11:40 AM, Scott Smith <ssm...@mainstreamdata.com>wrote: > In my environment, one of the concerns is that new documents are > constantly being added (and some documents may be deleted). This means > that when a user does a search and pages through results, it is possible > that there are new items coming in which affect the search-thus changing > where items are in relation to the pages displayed to the user. > > > > It seems to me that one solution would be to cache the Searcher for the > duration of the user's search session so that the user's view of the > available documents doesn't change. As I understand it, the user won't > see any changes to the index until a new Searcher is created. However, > I'm very sensitive to the amount of session context memory that caching > the searcher might take up. How much memory will caching the searcher > cost? Are there other tradeoff's I need to consider? > > > > Is this a viable option or does anyone have an alternative suggestion? > >
