: If documents are being added to and removed from an index (and commits : are being issued) while a user is searching, then the experience of : paging through search results using the obvious solr mechanism : (&start=100&Rows=10) may be disorienting for the user. For one : example, by the time the user clicks "next page" for the first time, a : document that they saw on page 1 may have been pushed onto page 2. : (This may be especially pronounced if docs are being sorted by date.)
FWIW: I've found that in practice this doesn't cofuse users as much as you might think. people understand that data changes, epecially when dealing with webpages, so they don't tend to freak out when results "shift" as long as it's clear why (ie: the total number of results increases/decreases) in the age of twitter, providing consistent results to a user during their entire session may actually frustrate them more then having inconsistent results as the data changes ... if they *know* that updates are happening frequently on the backend, but their searches all look static, that can be an even more unpleasent user experience. : #1: Cache results in the user session of the web tier. (In particular, : maybe just cache the uniqueKey of each maching document.) if it's really important to you, that would be my suggestion. it has the advantage of requiring session affinity oly at the higest level, without attempting to push it down into Solr. : Con: May require capping the # of search results in order to make : the initial query (which now has Solr numRows param >> web pageSize) : fast enough. For example, maybe it's only practical to cache the first : 500 records. that's pretty much all that's practical for paginated search anyway. : per-user results cache. You then also provide an API that says, "give : me records n through m of userid #1334's last search". For your : subsequent queries, you consult the latter API rather than redoing : your search. Because Lucene docids are unstable across commits and : such, I think this means caching the uniqueKey of each maching : document. This in turn means looking up the uniqueKey of each maching this still doesn't handle the case f documents getting dleted though ... now you have the uniqueKey of a doc you can't show anyway. -Hoss
