lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Smith" <>
Subject caching an indexreader
Date Fri, 19 Jun 2009 18:40:26 GMT
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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message