在会话中存储数据,如何以及何时检测数据是否过时

发布于 2024-11-28 02:09:47 字数 357 浏览 0 评论 0原文

我的场景是这样的。

  1. 用户进行搜索
  2. 处理程序找到结果,存储在会话中
  3. 用户查看结果,决定单击其中一个进行查看
  4. 查看后,用户单击“返回搜索”
  5. 处理程序检测到其返回搜索,跳过搜索,而是从会话中检索
  6. 用户看到与预期相同的结果

在#5,如果创建了一个新项目并且符合用户的搜索条件,那么它应该是结果的一部分。但由于在 #5 中我只是从会话中检索它不会检测到它。

我的问题是,我应该做额外的检查步骤吗?如果是这样,如何在不进行实际检索的情况下进行有效检查(这会达不到目的)?也许可以选择 count(*) .... 并将其与会话中结果集的计数进行比较?

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 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

简单 2024-12-05 02:09:47

我强烈建议不要在会话中缓存某些搜索结果。 Web 应用程序应努力拥有尽可能最小的会话状态。放入总括逻辑来根据用户会话状态缓存搜索结果(大概至少有几个 kb)实际上会带来内存问题。

相反,您应该有一个管理自己的缓存的单例搜索服务。虽然这在策略上看起来与会话内缓存类似,但它有几个优点:

  • 您可以在用户之间重复使用公共搜索结果;根据搜索类型,这可能很重要,
  • 您可以在服务层中管理缓存大小;像 ehcache 这样的东西很容易实现,并为您提供大量可配置性(并防止内存不足问题),
  • 您可以在服务层中管理缓存有效性;即,如果“更新项目”服务已触发其 save() 方法,则它可以告诉搜索服务使其整个缓存无效或仅使与新更新/创建的项目相对应的缓存结果无效。

上面的第三点解决了您的主要问题。

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.

七度光 2024-12-05 02:09:47

这取决于您的业务需求。如果用户必须获得最新的结果,那么您就必须撤回它们。

计数不会是 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.

眼藏柔 2024-12-05 02:09:47

为了查看是否有新项目,您可能必须重新运行搜索 - 即使只是为了获得计数。

您正在有效地缓存搜索结果。因此,正常的答案是要么在设定的时间后使结果过期(例如,结果仅在 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.

脱离于你 2024-12-05 02:09:47

您期望数据库项目的刷新率是多少?即使在很短的时间内,搜索结果也会发生巨大变化,因为我不知道这种情况,但你可能有不同的情况。

假设您的数据库由一个或多个单独的线程填充,并且您有另一个独立的线程来搜索结果,请跟踪插入缓存中数据库的最新项目的时间戳。

现在,当用户想要再次查看搜索结果时,比较时间戳,即将缓存时间戳与插入数据库的最后一个项目的时间戳进行比较。如果没有匹配,则从缓存中重新查询 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文