分页查询总行数缓存策略

举手，我问一下。

用SQL分页不就行了么。

统一有一个缓存机制实现常用数据的缓存。

我提一个最简单的实现方式，用SQL做key，用ObjectPool放结果集。


还有，为什么用户要关心你的缓存呢？要手动刷新？

同一个Action（Struts）或者Controller（Spring MVC）的用户的权限是一样的，权限控制根本不应该在Action或者Controller中实现。
用户是不用关心行数的变化的，他们只关心自己需要的数据有没有看到。。。
你的建议我会考虑，谢谢！

同一个ACTION的用户权限是一样的？你说的是功能权限吧？如果你说的是数据权限一样，难道同样是查一个表，要为不同权限的人写不同的ACTION吗？

感觉你像深圳这边的. 到你主页一看还真是.. 在深圳做外贸的确实很多. 感觉哪个方面适合自己就去做. 考虑自身情况就好.

1. 对于缓存的有效性而言，数据操作的性质是至关重要的，也就是如果读远大于写，以及数据的准确数量并不是最重要的信息时（也就是数据量远大于每页的数据行数），使用缓存来处理分页才是有效的。举个简单例子，一个查询会返回上万级的数据结果集时，那么数据总量及页数的是不必那么精确的，因为没有人会关心以及验证这个信息。从这个角度讲，基于页面的缓存最适合的是互联网系统，而不是企业业务系统。
2. 楼主将URL从web传递到DAO，是种非常不可取的做法，这种穿透性根本就破坏了层之间的依赖关系。换句简单的表达，这是MVC最起码的原则了。
3. 即使是URL，也只能处理Get的访问，对于基于Post的表单查询（会有童鞋质疑为什么要用post），楼主又如何获取一个唯一的URL呢？一个有效地改进是对查询条件对象或者生成的SQL进行数据摘要，但它有个前提，也就是摘要所花费的时间也要远小于统计数据的时间。当然，它又有下面的问题。
4. 我们说查询缓存对于什么样的情况最有用呢？不同的用户会使用相同的查询条件么？如果大家使用几乎不相同的查询条件，那么这个缓存也就是失去了意义，会反复地更新而不是读取。所以，要解决这个问题，必须清楚实际项目的应用情况，做好更准确的分析。

     说明上面这些，其实是想让楼主看看另外一篇讨论ORM缓存的帖子，缓存的应用是一个比较深的学问。去写一个缓存实现，去应用一个缓存组件都非常简单，复杂就复杂在不同系统，不同应用场景，缓存的不同应用有很大的区别。

我觉得，还是根据不同的应用场景，来理解楼主的想法，应该是挺好的。

1，楼主提到了高并发，应该看下com.java.util.concurrent包下的ConcurrentHashMap

2，单纯靠判断时间来对缓存进行删除操作我觉得不太科学，是否可以加一个计数器？在使用频率最少和时间之间做判决。

3，是否可以扩展一下让这个缓存应用到不同的场景，比如存取可能是一些实际的对象，或者删除之后是否可简单持久化到文件，下次读取文件的一些关键信息。（有一些操作很占内存不一定是DAO，比如一些文件的解析）

4，维护多个有关联的Map的时候是否需要加入事务处理。

另外凤舞凰扬提到的这里只能应用于GET请求也是一个短板，最近刚好也有一个项目里有缓存的内容，愚见。

你的想法不错，呵呵，缓存方案其实已经有很好的实现OSCache等，对象缓存、查询缓存等等这些较复杂的东西可以使用现有的缓存系统集成就行了。我对缓存其实也不是很了解，只是写一点自己的想法，一起讨论下。。。

本着讨论的精神，自己考虑下这些东西比直接用framework要来的有帮助

既然是高并发，那是否应该考虑同步机制？