opensessioninview

robbin:

我写了一个简单的webapp在Tomcat5.5.12上面做了一个小测试。在JSP页面里面循环1万次输出字符串，程序在远程服务器上面运行，网络是ADSL宽带，filter确实被阻塞了20秒左右。然后我另外开了一个flashget去下载服务器上的大文件，模拟网络速度比较慢的环境，filter被阻塞了50秒左右。分别做了三次测试。另外当页面下载过程中直接点击浏览器stop按钮，则JSP执行被打断，filter立刻解除阻塞，被执行完毕。

结论证明，使用OpenSessionInView的时候，如果render的页面数据量非常大，并且客户端网络速度很慢的情况下，由于页面的输出时间过程很长，确实会造成filter被长时间阻塞。对于OpenSessionInViewFilter来说，就会造成数据库连接被保持很长的时间，才能被关闭。

不过，对于Spring的OpenSessionInViewFilter来说，虽然数据库连接被保持了过长的时间，但是并没有锁定数据库资源，特别是事务资源。因为Spring的事务是通过TransactionInterceptor来实现的，在MVC结构中，当最后一个业务bean被调用结束以后，Transaction就已经被提交了。此后，虽然数据库连接还保持中，但是数据库资源没有锁定问题。

完整的调用示意图：

request -> (OpenSessionInViewFilter打开Session) ->  ServletDispatcher -> Action -> (打开Connection，启动事务) -> spring bean -> another spring bean -> (提交事务) -> bean执行完毕，返回Action -> render view(JSP/Template) -> (OpenSessionInViewFilter关闭Session和Connection)

 

 

 

-----------------------------------------------

downpour 写道

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

引用

对于Spring的OpenSessionInViewFilter来说，虽然数据库连接被保持了过长的时间，但是并没有锁定数据库资源，特别是事务资源。

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

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

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

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

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

---------------------------

hongliang 写道

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

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

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

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

-----------------------------------

hongliang 写道

是不是像这样？

foo.getBars()

Hibernate.initialize(foo.getBars);