| Blog信息 |
|
blog名称:
日志总数:1304
评论数量:2242
留言数量:5
访问次数:7628406
建立时间:2006年5月29日 |
| |
|
 [Hibernate]OpenSessionInView会不会影响性能
软件技术, 电脑与网络
lhwork 发表于 2006/7/6 14:56:33 |
| 假设WebWork+Hibernate+FreeMarker架构模型是这样的
Request||---other filters...||---OpenSessionInView Filter||-----WebWork Controller||---Action||---FreeMarker Result(对response.getWriter()做process()操作)|||---OpenSessionInView Filter||---other filters...|Request
这里有两种情况。
一是页面缓冲区足够大，足够一次性容纳所有的页面，这样渲染页面就会一次性进入缓冲区，然后返回到OpenSessionInView Filter，关闭Session，数据库连接返回池中，一切OK。
第二种情况我是重点想讨论的，也是我的疑虑所在。那就是假如这个页面比较大，超出页面缓冲区的大小，那么渲染页面时，就拿
FreeMarker/Velocity这样的模板语言来说，它执行process/merge方法，往servlet的response
writer/outputStream里面写东西，写着写着，发现写不动，是缓冲区满了，而这个writer/outputStream，正是服务器同
用户之间建立的socket请求，于是底层代码开始先向用户传输一部分页面，传好后，又有新的缓冲区，FreeMarker/Velocity的方法又能
向缓冲区里写东西叻。而传输页面这个过程，又耗费几秒钟的时间，就导致数据库连接被占用很长的时间。
robbin write:
我写了一个简单的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)
当然，按道理来说，数据库连接应该尽早被释放，以缓解数据库资源的压力，延迟很久才释放，确实会导致需要更多的数据库连接。这个就只能扩大连接池数量，增加数据库最大允许连接数来解决了。
此外，Session被延迟很久释放，那么Session占用的一级缓存也会占用比较长时间，这意味着会无谓消耗更多的JVM内存。
因此，OpenSessionInView虽然确实方便，但是大家还是慎用吧。对于那些页面渲染速度很慢，拨号连接用户数量过多的网站就最好不要使用。 |
|
|