Hibernate Iterator JCS分析

当数据少的时候，问题不是很大的
可是有没有想过，当数据库的记录数很多的
并发访问用户多的时候，Iterator 就是噩梦了
用户在一个时刻，怎么可能会做反复的查询呢
往往都是个人查询个人的东西，记录也不交叠
这有作Iterator的必要么
模拟一个真实环境好了，用户列举网费的清单纪录
假设高峰时200用户同时查询，每个用户一次查询的流水
大约100条，再假设平均100记录中有10%的是没有缓冲过的，ok在一个点上服务器要做2000次的查询，而缓冲好的数据，却又是没有任何意义的数据，可以被反复查询的几率非常的低
话说回来，有人说了那可以一次性 select * table把所有的数据放进来阿，然后全靠缓冲数据提供服务的，可是注意一下，缓冲可不是永远有效的，是会过期的，留下一个未知性能陷阱在那个地方，你永远不会知道，在什么时候什么人会去访问数据的，怎么办？永久性的catch,太可怕了，不光要无限制的消耗我的cpu还要消耗我的内存
太可怕了，当jvm管理的内存超过512的时候，我不继续想想下去的
如果下一代的hibernate可由条件进行缓冲或者提供自定义函数缓冲，或者我们会有更好地解决办法，而我目前的解决办法是list,不过记录总数要是小于1000的话，iterator是个好地解决方案，不会造成太大的负荷，又可以满足性能的需要

楼上的说法我认为有片面性，其实我个人感觉Iterator就像计算机里面的cache一样，按照楼上的观点，岂不是完全否定了cache的这种作用嘛？数据的空间局部访问和时间局部访问总是存在的嘛。

注意我不是反对使用iterator的缓冲地位
我只是在设计的过程中，发现如果使用数据库的各个
用户的，他们所使用的纪录交叠性不强，并且表中的纪录
非常多的情况下，那么iterator就将是设计人员的梦魇了
并发量越大,hibernate的性效就越低的

JCS不是取消了么
现在改成cache provider