SearcherLifetimeManager prevents a broken search user experience
From the post:
In the past, search indices were usually very static: you built them once, called optimize at the end and shipped them off, and didn’t change them very often.
But these days it’s just the opposite: most applications have very dynamic indices, constantly being updated with a stream of changes, and you never call optimize anymore.
Lucene’s near-real-time search, especially with recent improvements including manager classes to handle the tricky complexities of sharing searchers across threads, offers very fast search turnaround on index changes.
But there is a serious yet often overlooked problem with this approach. To see it, you have to put yourself in the shoes of a user. Imagine Alice comes to your site, runs a search, and is looking through the search results. Not satisfied, after a few seconds she decides to refine that first search. Perhaps she drills down on one of the nice facets you presented, or maybe she clicks to the next page, or picks a different sort criteria (any follow-on action will do). So a new search request is sent back to your server, including the first search plus the requested change (drill down, next page, change sort field, etc.).
How do you handle this follow-on search request? Just pull the latest and greatest searcher from your SearcherManager or NRTManager and search away, right?
Wrong!
Read at the post why that’s wrong (it involves getting different searchers for the same search) but consider your topic map.
Does it have the same issue?
A C-Suite users queries your topic map and gets one answer. Several minutes later, a non-C-Suite user does the same query and gets an updated answer. One that isn’t consistent with the information given the C-Suite user. Obviously the non-C-Suite user is wrong as is your software, should push come to shove.
How do you avoid a “broken search user experience” with your topic map? Or do you just hope information isn’t updated often enough for anyone to notice?