关键字:查询,事务,粒度

你这个回答简直太搞笑了，“我有新的关注点－－事务”，难道你没有看原文吗？？？？？？？？？？
我原来的关注点就是事务，被人引导并发上去了，你看不出来吗？？

本来我以为这种问题挺简单的，发了文章之后我都后悔，觉得太简单了，没想到还有这么多人到现在还是搞不清楚

----------------------------------------------------------------------
我在第四页的回帖已经说了很清楚了，即使加上并发connection还是会被耗尽的，因为并发不是connection耗尽的原因，为什么怎么说都不明白呢

ps:关于并发问题，我已经在第三页做了较为详细的阐述，看贴要仔细，思考要深入，发言要谨慎

按我说就把容器的output buffer设置大，然后用filter保证connection open in view.
请求到页面渲染的时间是固定的，只要保证请求的处理时间内能有空余的connection就ok了，这个connectin的数量应该不需要很大。反而事务粒度设置很小，每个请求假设要拿100次连接，连接池的锁竞争开销不小。
(这个方法纯属猜测，因为servlet规范没说清楚dochain后的执行与完成响应输出之间的先后关系)

对于大型网站来说，并发的request可能上百，如果connection都在filter里面打开并维持到render结束，连接池岂不是要设置很多connection数才够？

屏蔽网络的影响，看机器在多少个并发的时候达到最好的性能，这个并发数应该就是连接数了。

问题是，一个数据库可能要被很多个应用使用，按照你这种方式来确定连接数的话，恐怕就数据库层面很难权衡。为什么允许你某个应用有那么多个连接数来连我？

我碰到的实际情况是，有一些客户根本对数据库连接数相当关心，一个应用顶多给你50个连接，请问此时你如何解决这个问题。

问的好，答案你也知道，我就不重复一些yy废话了。实际点要看具体的测试，毕竟不是常说数据库与代码的执行不是一个数量级吗。

实在不好意思，现在才完全读完第3页、第4页，多想了一些东西，然后也做了小程序来验证....
读技术帖子向来很慢，见笑了....     解决问题是一回事，更合理又是一回事...
之前有跑题，收住

但是事务仅仅发生在有事务资源参与的部分，貌似不应该太多次调用到getfromDB方法，缓存的命中率是否也有一定问题？

而你在开贴的结论中提到

实际上所说的加锁，也是保证不多次读取数据库，而直接从缓存获得的一种保障；
这个connectoin耗尽的根本原因在cache中的命中率不高而导致


这个分析，相当好，也是我多次读这个文章中一再受益的

这个是performance tuning用的，不是解决问题用的吧

我以前很少研究事物。
楼主建议缩小事务粒度，但是我们使用transaction最初的目的是为了减少原来jdbc事务繁琐的代码，我看了一些书，说要是把事务粒度界定在dao方法上，无法保证多个dao方法的事务完整性，放在service上的话，因为事物是persistance层的，显然有点破坏了分层。
那该怎么办呢？

应该是粗粒度的事务，和 大量的并发，才会造成connection耗尽的情况
如果一个事务，耗时时间几乎不计，那再多的并发也不会造成connection耗尽，不考虑tomcat之类容器的原因，
再粗粒度的事务，没有并发，也不会造成connection耗尽
所以抛开两者任何一个来说都是不客观的
opensessioninview 也是同样的道理，每个session占用的connection时间过长，请求一旦过多，就造成请求延迟的情况
楼主的代码没有错，通常我们遇到的逻辑处理不可能也不应该在底层加锁来解决，试想，是让并发的这些线程在第一次访问的时候都访问数据库好，  还是所有的线程在访问底层代码的时候都加锁好，毫无疑问肯定是前者好
前面那位兄弟提到的FutureTask，可能适合你的特殊的业务逻辑，并不适合所有的开发环境当中
个人理解