Store data in session, how and when to detect if data is stale

The scenario I have is this.

1. User does a search
2. Handler finds results, stores in session
3. User see results, decides to click one of them to view
4. After viewing, user clicks to "Back to Search"
5. Handler detects its a back to search, skips search and instead retrieves from session
6. User sees the same results as expected

At #5, if there was a new item created and fits the user's searc开发者_开发百科h criteria, thus it should be part of the results. But since in #5 I'm just retrieving from session it will not detect it.

My question is, should I be doing an extra step of checking? If so, how to check effectively without doing an actual retrieve (which would defeat the purpose)? Maybe do select count(*) .... and compare that with count of resultset in session?

---

Caching something search results in a session is something I strongly advise against. Web apps should strive to have the smallest session state possible. Putting in blanket logic to cache search results (presumably several kb at least) against user session state is really asking for memory problems down the road.

Instead, you should have a singleton search service which manages its own cache. Although this appears similar in strategy to caching inside the session, it has several advantages:

• you can re-use common search results among users; depending on the types of searches this could be significant
• you can manage cache size in the service layer; something like ehcache is easy to implement and gives you lots of configurability (and protection against out of memory issues)
• you can manage cache validity in the service layer; i.e. if the "update item" service has had its save() method triggered, it can tell the search service to invalidate either its entire cache or just the cached results that correspond with the newly updated/created item.

The third point above addresses your main question.

---

It depends on your business needs. If it's imperative that the user have the latest up to date results then you'll have to repull them.

A count wouldn't be 100% because there could be corresponding deletions.

You might be able to compare timestamps or something but I suspect all the complexity involved would just introduce further issues.

Keep it simple and rerun your search.

---

In order to see if there are new items, you likely will have to rerun your search - even just to get a count.

You are effectively caching the search results. The normal answer is therefore either to expire the results after a set amount of time (eg. the results are only valid for 1 minute) or have a system that when the data is changed, the cache is invalidated, causing the search to have to run again.

Are there likely to be any new results by the time the user gets back there? You could just put a 'refresh' button on the search results pages to cause the search to be run again.

---

What kind of refresh rate are you expecting in the DB items? Would the search results change drastically even for short intervals, because I am not aware of such a scenario but you might have a different case.

Assuming that you have a scenario where your DB is populated by a separate thread or threads and you have another independent thread to search for results, keep track of the timestamp of the latest item inserted into the DB in your cache.

Now, when user wants to see search results again compare the timestamps i.e. compare your cache timestamp with that of the last item inserted into the DB. If there is no match then re-query else show from your cache.

If your scenario confirms to my assumption that the DB is not getting updated too frequently (w.r.t. to a specific search term or criteria) then this could save you from querying the DB too often.