spring的事务配置 20
spring的局部事务配置,通过切入点产生事务代理进行事务增强,那对于一个业务逻辑,在执行切入点函数之前就已经打开事务,当然打开事务之前先得打开session,最后函数执...
spring的局部事务配置,通过切入点产生事务代理进行事务增强,那对于一个业务逻辑,在执行切入点函数之前就已经打开事务,当然打开事务之前先得打开session,最后函数执行完后提交事务,并关闭session,那就是说dao中的hibernatetemplate执行的get方法的具体操作方法是不需要再进行事务和session操作的吗?
我理解不对的地方 请大神指明。。。 展开
我理解不对的地方 请大神指明。。。 展开
展开全部
这是一般规范配置事务的,根据业务需求可以改expression路径,和前缀方法
从我这个配置文件来讲,事务是从service。前缀方法()开始给这个方法添加事务,而这个方法的实现是在serviceImpl类里,这个类里你又调用了dao。XXX方法等很多操作,但因为从第一入口类(就是你调用那个service。前缀方法)开始已经开启了一个事务,当然先开启session 然后对应N个事务,而这个session又管理到你执行完最后方法(比如你的dao的查询,更新等),到你这个入口类方法结束出来时候 spring给你管理事务的commit和session的关闭。具体怎么封装好的我也不清楚,但你要注意的是上面配置的每个属性代表什么意思,注重的是什么时候开启事务,什么时候不开启事务等
希望对你有所帮助
更多追问追答
追问
一个session哪来的n个事务
追答
比如说你用service。createXX方法开启了一个session 并添加了一个事务是不?然后在createXX方法类里可以有N个事务
实际例子:
serviceA。recover()---比如在service层调用了这个方法,开启了一个session但没添加事务。
在serviceImpl类的recover方法里, 有个serviceB。createXXX方法 这时候根据你封装好的getCurrentSession取了serviceA的session 并添加了B事务,又在下面调用serviceC。saveXXX方法,添加C事务,以此类推,这么做的好处在于,由于serviceA。recover方法故意没添加事务,recover里面的事务都是各走各的,如果recover中途出了异常,回滚的都是当前的一个对象,之前create和update的正常执行完,而当你在serviceA直接开启了事务,里面的serviceB,serviceC的事务默认包含在A,当serviceA中途报错了 会回滚全部。这些都在实际开发中根据你的业务需求而使用
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询