OpenSessionInView会不会影响性能？

robbin的分析很透彻，对于最后一点，我稍有疑问。



其实我认为数据库连接被保持过长时间有时候会有很大的问题。尤其是对于采用数据连接池的情况，如果你的数据库连接一直被保持，那么这个资源就未被释放。假设说这个数据连接池的最大连接数为15，我感觉很容易造成数据库的连接不够用。

不清楚底层的实现是如何做的，或许我的疑问有些多虑。

按道理来说，数据库连接应该尽早被释放，以缓解数据库资源的压力，延迟很久才释放，确实会导致需要更多的数据库连接。这个就只能扩大连接池数量，增加数据库最大允许连接数来解决了。

此外，Session被延迟很久释放，那么Session占用的一级缓存也会占用比较长时间，这意味着会无谓消耗更多的JVM内存。

因此，OpenSessionInView虽然确实方便，但是大家还是慎用吧。对于那些页面渲染速度很慢，拨号连接用户数量过多的网站就最好不要使用。

几天没来，居然变精华叻。。。本来我也想做一下robbin的那个测试，结果这几天忙于其它事，一直没时间。看来OpenSessionInView果然有这个问题，这也是我一直担心的，看来真是应叻那句话，“如果一件事可能出错，那它一定会出错”。。。

不过，如果不用OpenSessionInView，我还真一下子就找不到北叻，从学Hibernate开始就一直在OpenSessionInView的熏陶下长大。。。-_-b

Robbin有什么好的办法能够在不使用OpenSessionInView的情况下比较好的处理页面吗？

确切的应该是大并发用户量的情况吧。这个问题一直都存在，在1年多前我和robbin争论中就提出来了过。hibernate2的代码可以看到session是和connection紧密耦合的（Hibernate3没看过）。但hibernate大部分被用于并发用户可预见的intranet应用，所以问题也不是很大。如果并发用户多，对connection pool资源, opensession in view在hibernate中使用会构成较大压力。如果jboss j2ee5 server采用hibernate作为ejb3实现，没有做修正的话，同样的问题也会存在于jboss j2ee5 server中。

在dao中对要render的集合强制初始化。

是不是像这样？

foo.getBars()

Hibernate.initialize(foo.getBars);

一个可能的解决办法：
wrap一个response，在页面渲染完后，立即关闭session，再把wrap的response的内容用服务器的response写出，可能行。。

更根本的解决办法是服务器提供aio,nio的支持

既然是在DAO中,怎么会知道什么时候要render集合, 难道每个DAO方法对应一个业务方法?

如果是数据传输量比较大，并发比较大的系统，建议先做压力测试，个人不推崇sessionInView的方式。作完压力测试比较一下就知道结果了。