记录我在使用spring,hibernate的时候遇到的session,和事务管理的问题.

spring用一个OpenSessionInView的filter来处理session was closed的问题.这个大家并不陌生. 我们项目当中的dao层有一个baseDao. 封装了一系列对持久化对象的操作方法.C,R,U,D 条件查询.分页查询.等等.而且baseDao当中的所有的find方法都是readOnly的,get和load直接调用的 hibernateTemplate的get和load.当然service层当中的事务管理也是使用spring的那个事务模板.

     		
      			
       		
      	
     		 	
     		
      			
       		
      		
      			
       				
        
         PROPAGATION_REQUIRED
        				
        
         PROPAGATION_REQUIRED
        				
        
         PROPAGATION_REQUIRED
        				
        
         PROPAGATION_REQUIRED
        				
        
         PROPAGATION_REQUIRED
        				
        
         PROPAGATION_REQUIRED,readOnly
        				
        
         PROPAGATION_REQUIRED,readOnly
        				
        
         PROPAGATION_REQUIRED
        			
       		
      	
     

以上配置都OK.

我遇到的问题有几个, 如下:

问题1,需要实现这样一个业务逻辑: 先把对象find出来.然后改变某个属性.然后在update. 在service当中就会写这样一个方法.changeOrder.在changeOrder当中先用dao的find.然后在用dao的update. 理论上是可行的.因为service的事务都是被spring的事务模板托管.而且changeOrder得到的connection是可写的.(因为 spring的事务模板根据对方法名的匹配来判断获得得connection类型).但是由于baseDao.当中的所有find方法都是 setReadyOnly(true). 这样.当在service执行任何find的时候.baseDao将强行把connection改为只读的.接下来在一个事务当中.任何update 和save动作都不能完成了.但是直接执行hibernateTemplate的get和load却不会出现这个问题.因为这个connection的属 性是由spring的openSessionInView来处理的.在request一过来的时候spring会绑定一个session.到 request.直至request结束.(在这段过程当中如果不认为改变connection的readOnly的属性.这个connection将会 从请求一开始到结束都是可以写入的.)

解决的办法就是在自己的dao当中将find方法重载.将readOnly改为false.

问题2, 有两个方法.一个是get对象.一个是find对象.同样也是直接调用baseDao的get和find方法.

当我对一个对象进行编辑操作的时候发现service当中的update是有效的. 但是我find出来的对象.在利用service当中的update来更新却发现没有任何异常.但是就是更新不了对象.

后来才明白.get方法当中是没有对connection进行任何readOnly相关的操作.但是baseDao当中却设置了只读..这个时候 又有一些疑问了. action并没有进行事务管理.当先调用service的find方法(也就是调用了baseDao中的find方法).这一个事务已经提交了.然后在 继续调用service的update.为什么会更新不了对象?

原因就是在于OpenSessionInView.绑定的一个session对象在这一次的request当中.所以.从一次request.开 始到结束.这个request仅仅会操作当前的一个session对象. 尽管在action当中连续调用的两次service方法都有两个不同的事务范围.在一整个请求当中还是只存在一个session对象.

所以第一个service的find方法执行完毕之后已经将当前request范围内的session改成了readOnly.以后的所有的 service操作都是只读的.后面的service一些save或者update方法都会失效.....这就是OpenSessionInView和事 务之间的微妙关系.

问题3,在ajax异步调用当中.经常也会出现这一系列的问题.其实原理大都是一样.因为ajax后来也是一个以.dwr结尾的请求.在 OpenSessionInView当中加入一个filtermapping 为 .dwr 这样它会拦截所有的.dwr请求.在所有的ajax操作当中会绑定一个session对象.

总结一下: OpenSessionInView是一个filter.它会为每一个request绑定一个session.任何接下来在这一次请求当中所有的 hibernate操作.都是基于当前请求的这个session的.任何service或者dao把当前的session对象改为了readOnly后. 接下来所有save or update操作将进行不了.尽管他们不是在一个service方法(不是在同一个事务当中进行).

BTW.service在很大程度上是可以和dao层混合到一起.这样可以节约很多代码.但是.也会带来维护的时候非常的负责.并且麻烦.特别是readOnly 和session was closed问题.会另你非常的沮丧.

dao实际上是不需要用transaction来管理的.真正需要事务的是项目当中的service层.理解才是最重要的.用好OpenSessionInView会给项目带来极大的方便.