在会话中存储数据,如何以及何时检测数据是否过时
我的场景是这样的。
- 用户进行搜索
- 处理程序找到结果,存储在会话中
- 用户查看结果,决定单击其中一个进行查看
- 查看后,用户单击“返回搜索”
- 处理程序检测到其返回搜索,跳过搜索,而是从会话中检索
- 用户看到与预期相同的结果
在#5,如果创建了一个新项目并且符合用户的搜索条件,那么它应该是结果的一部分。但由于在 #5 中我只是从会话中检索它不会检测到它。
我的问题是,我应该做额外的检查步骤吗?如果是这样,如何在不进行实际检索的情况下进行有效检查(这会达不到目的)?也许可以选择 count(*) .... 并将其与会话中结果集的计数进行比较?
The scenario I have is this.
- User does a search
- Handler finds results, stores in session
- User see results, decides to click one of them to view
- After viewing, user clicks to "Back to Search"
- Handler detects its a back to search, skips search and instead retrieves from session
- User sees the same results as expected
At #5, if there was a new item created and fits the user's search 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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我强烈建议不要在会话中缓存某些搜索结果。 Web 应用程序应努力拥有尽可能最小的会话状态。放入总括逻辑来根据用户会话状态缓存搜索结果(大概至少有几个 kb)实际上会带来内存问题。
相反,您应该有一个管理自己的缓存的单例搜索服务。虽然这在策略上看起来与会话内缓存类似,但它有几个优点:
上面的第三点解决了您的主要问题。
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:
The third point above addresses your main question.
这取决于您的业务需求。如果用户必须获得最新的结果,那么您就必须撤回它们。
计数不会是 100%,因为可能存在相应的删除。
您也许可以比较时间戳或其他东西,但我怀疑所涉及的所有复杂性只会引入进一步的问题。
保持简单并重新运行搜索。
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.
为了查看是否有新项目,您可能必须重新运行搜索 - 即使只是为了获得计数。
您正在有效地缓存搜索结果。因此,正常的答案是要么在设定的时间后使结果过期(例如,结果仅在 1 分钟内有效),要么使用一个系统,当数据更改时,缓存会失效,从而导致搜索必须再次运行。
当用户返回那里时是否可能有任何新结果?您只需在搜索结果页面上放置“刷新”按钮即可再次运行搜索。
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.
您期望数据库项目的刷新率是多少?即使在很短的时间内,搜索结果也会发生巨大变化,因为我不知道这种情况,但你可能有不同的情况。
假设您的数据库由一个或多个单独的线程填充,并且您有另一个独立的线程来搜索结果,请跟踪插入缓存中数据库的最新项目的时间戳。
现在,当用户想要再次查看搜索结果时,比较时间戳,即将缓存时间戳与插入数据库的最后一个项目的时间戳进行比较。如果没有匹配,则从缓存中重新查询 else show。
如果您的场景证实了我的假设,即数据库没有过于频繁地更新(针对特定的搜索词或条件),那么这可以使您免于过于频繁地查询数据库。
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.