我的场景是这样的。
- 用户进行搜索
- 处理程序找到结果，存储在会话
- 用户看到结果，决定点击其中一个查看
- 查看完毕后，用户点击"返回搜索"
- 处理程序检测到它的返回搜索，跳过搜索，而是从会话 中检索
- 用户看到与预期相同的结果
在#5，如果有一个新项目创建，并符合用户的搜索条件，因此它应该是结果的一部分。但由于在#5我只是从会话检索，它不会检测到它。
我的问题是，我应该做一个额外的检查步骤吗?如果是这样，如何在不进行实际检索(这会破坏目的)的情况下有效地进行检查?也许可以选择count(*) ....并将其与会话中resultset的计数进行比较?
在会话中缓存某些搜索结果是我强烈反对的。Web应用程序应该努力拥有尽可能小的会话状态。根据用户会话状态，使用毯子逻辑来缓存搜索结果(大概至少几个kb)，实际上是在自找内存问题。
相反，你应该有一个单独的搜索服务来管理它自己的缓存。虽然这在策略上看起来与在会话中缓存类似，但它有几个优点:- 可以在用户之间重复使用常用的搜索结果;根据搜索的类型，这可能是重要的
- 可以在服务层管理缓存大小;像ehcache这样的东西很容易实现，并为您提供了大量的可配置性(并防止内存不足问题)
- 可以在服务层管理缓存有效性;例如，如果"update item"服务已经触发了save()方法，它可以告诉搜索服务使其整个缓存无效，或者只是缓存与新更新/创建的项目对应的结果无效。
这取决于您的业务需求。如果用户必须拥有最新的结果，那么你就必须重新拉出它们。
计数不会是100%，因为可能存在相应的删除。
你可能能够比较时间戳或其他东西，但我怀疑所有涉及的复杂性只会引入更多的问题。
保持简单，重新搜索
为了查看是否有新项目，您可能需要重新运行搜索-即使只是为了获得计数。
您正在有效地缓存搜索结果。因此，正常的答案是要么在一段时间后将结果过期(例如:结果仅在1分钟内有效)，或者当数据更改时，系统中的缓存无效，导致必须重新运行搜索。
当用户返回时，可能会有任何新的结果吗?你可以在搜索结果页面上放一个"刷新"按钮，让搜索再次运行。
您期望DB项的刷新率是多少?搜索结果是否会在很短的时间间隔内急剧变化，因为我不知道这种情况，但您可能有不同的情况。
假设你有一个场景，你的数据库是由一个或多个单独的线程填充的，并且你有另一个独立的线程来搜索结果，请跟踪在缓存中插入数据库的最新项的时间戳。
现在，当用户想要再次查看搜索结果时，比较时间戳，即将缓存时间戳与插入数据库的最后一项的时间戳进行比较。如果没有匹配，则从缓存中重新查询。
如果您的场景证实了我的假设，即数据库没有更新得太频繁(例如特定的搜索词或标准)，那么这可以使您避免过于频繁地查询数据库。