SearcherLifetimeManager

Keeps track of current plus old IndexSearchers, closing the old ones once they have timed out.

Use it like this:

SearcherLifetimeManager mgr = new SearcherLifetimeManager();

Per search-request, if it's a "new" search request, then obtain the latest searcher you have (for example, by using SearcherManager), and then record this searcher:

// Record the current searcher, and save the returend
// token into user's search results (eg as a  hidden
// HTML form field):
long token = mgr.record(searcher);

When a follow-up search arrives, for example the user clicks next page, drills down/up, etc., take the token that you saved from the previous search and:

// If possible, obtain the same searcher as the last
// search:
IndexSearcher searcher = mgr.acquire(token);
if (searcher != null) {
     // Searcher is still here
     try {
       // do searching...
     } finally {
       mgr.release(searcher);
       // Do not use searcher after this!
       searcher = null;
     }
} else {
     // Searcher was pruned -- notify user session timed
     // out, or, pull fresh searcher again
}

Finally, in a separate thread, ideally the same thread that's periodically reopening your searchers, you should periodically prune old searchers:

mgr.prune(new PruneByAge(600.0));

NOTE: keeping many searchers around means you'll use more resources (open files, RAM) than a single searcher. However, as long as you are using [DirectoryReader.openIfChanged], the searchers will usually share almost all segments and the added resource usage is contained. When a large merge has completed, and you reopen, because that is a large change, the new searcher will use higher additional RAM than other searchers; but large merges don't complete very often and it's unlikely you'll hit two of them in your expiration window. Still you should budget plenty of heap in the JVM to have a good safety margin.