Spring事务失效事件

近期遇到一个spring注解事务失效的问题,先上代码(以下代码经过简化,只保留关键点)。

        没耐心的朋友可以直接看最下面结论。

第一部分:具体问题

接下来上一下代码,大致介绍一下流程。

Controller

Controller里面使用@Autowired注入了一个serviceImpl,然后调用这个serviceImpl的业务方法。

ServiceImpl的属性

自动装配了另一个service和一个dao

重点看serviceImpl的方法(经过简化,只保留了关键点)

红框是两个insert数据库操作,需要事务管理

最下面的抛出异常是为了测试事务。

其中红框里面的super.addNew方法上有@Transactional(rollbackFor = Exception.class)注解。所以看上去并没有什么问题,但是每次抛出异常,数据库的操作都没有回滚。

问题大致就是这样,本来以为事情会很容易被解决,因为在网上看过很多事务失效的例子,各种原因被各种大神列举了很多次了。

第二部分:常规问题解决


普通事务失效原因:

1.如使用mysql且引擎是MyISAM,则事务会不起作用,原因是MyISAM不支持事务,可以改成InnoDB

2. 如果使用了spring+mvc,则context:component-scan重复扫描问题可能会引起事务失败。 (即父子容器)

3. @Transactional 注解开启配置,必须放到listener里加载,如果放到DispatcherServlet的配置里,事务也是不起作用的。

4. @Transactional 注解只能应用到 public 可见度的方法上。 如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解,它也不会报错,事务也会失效。

5. Spring团队建议在具体的类(或类的方法)上使用 @Transactional 注解,而不要使用在类所要实现的任何接口上。在接口上使用 @Transactional 注解,只能当你设置了基于接口的代理时它才生效。因为注解是 不能继承 的,这就意味着如果正在使用基于类的代理时,那么事务的设置将不能被基于类的代理所识别,而且对象也将不会被事务代理所包装。

以上五点摘抄自:Spring事务失效的原因


看到常规的原因,首先的解决思路如下

1.首先,数据库使用的是oracle,所以排除1

2.项目确实使用的是spring+mvc不过已经分开扫描了,mvc只扫描Controller和RestController,spring扫描排除这两个注解这样可以排除2,

3.事务管理器配置确实是放在spring容器里,用Listener加载的

4.方法是public

5.是在类的方法上使用的,非接口上

所以,常规的问题被我巧妙地全避开了。

第三部分:解决思路

这个事务失效问题是第一次出现,并没有广泛存在我们的系统中。于是和其他的事务方法对比,发现其他的事务方法都是通过Service.getInstance()方法获取到的实例,跟进去,发现getInstance方法是通过我们项目定义的工具类从xml里面getBean获取到的。看上去貌似没什么问题,getBean和使用@Autowired不都一样嘛,都能获取到bean。

打开日志debug级别,看能不能查到点什么细节。并且给方法入口和spring的事务管理器入口org.springframework.transaction.interceptor.TransactionInterceptor#invoke打上断点,然后运行到该事务方法。

首先在方法入口的断点处用evaluate expression执行AopUtils.isAopProxy这个方法来看一下注入的serviceImpl是否被代理了,结果是true。

继续执行,进入到spring事务管理器里面,然后一步步跟代码,获取TransactionInfo等,并没有发现什么可疑点,因为都已经进入到了spring事务管理器了,而spring几乎不会出bug,进入到方法第一行后,查看了下debug日志,发现有Creating new transaction with name [XXX]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT; '',-java.lang.Exception,继续执行,执行到super.addNew方法时,debug日志又出现了一行 Creating new transaction with name [XXX]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT; '',-java.lang.Exception,而且此XXX非刚才的XXX,意思是在第一个事务里面,又起了一个事务,但是我事务没有显示配置PROPAGATION,默认的是REQUIRED,为什么会又重新起一个事务呢,这里让我百思不得其解。于是我回过头又检查了一遍父子容器问题,是不是还是因为包扫描重复导致的呢,虽然如果是子容器(即MVC)的话,肯定不会进入到事务管理器,但我还是抱着侥幸心理检查了一遍,没有任何问题。

没找到问题所在,继续执行下去,发现跑出的异常被事务管理局接管了,debug日志也显示了transaction rollback。这就更奇怪了,既然事务都回滚了,数据是怎么插到数据库里的呢。我继续在插数据的那一行sql打上断点,重复执行,发现执行完这条sql的时候,数据就已经在数据库了,但是事务还没提交。。这又是怎么回事。这里我想到了会不会是数据库连接设置的autoCommit,于是重复执行,在spring的transaction源码里面打断点,发现事务管理器会自动把autoCommit关掉。

感觉这条追查的路已经堵死了。。反而产生了两个其他的问题,1.既然是PROPAGATION_REQUIRED,为什么会在事务里又起一个事务,2.既然事务都还没提交,你是怎么插入到数据库里的。。

想到最一开始观察到的,和其他事务起作用的方法差别在于,他们的成员变量是getInstance获得的,而这个有问题的是@Autowired注入的,那么是不是这里有问题呢,于是我把Autowired的全换成了getInstance获取在xml里面注册的bean,果然,事务起作用了。可是,这tm到底咋回事。。。Autowired和getBean不是一样么,为什么会出现两种截然不同的结果。刚好最近刚看完SpringIoc的源码,就决定追查到底。

第四部分:真相大白

理理思路,父容器先加载,子容器后加载,子容器在加载过程中会通过获取到父容器。

请求到达应用后,Controller会先被初始化,然后他的私有属性serviceImpl会被 inject,实质上是会被父容器inject,然后循环注入serviceImpl私有属性的私有属性。。一直循环直到所有的bean都被实例化。事务管理器也在父容器中定义,貌似没有问题,事实也证明了,事务管理器确实代理了目标方法。

然后深入看了下getInstance方法,这个方法是通过项目的一个工具类的getBean方法工作的,工具类的getBean方法实际上是new了一个ClassPathXmlApplicationContext,然后调用他的getBean方法,那么看到这里好像一切都明朗了。。

@Autowired自动装配的是web.xml里面定义的Listener加载的父容器里的bean,getInstance是自己定义的第二个容器获取到的bean,那么事务管理器也是一样,实际上有两个事物管理器,第一个是webxml加载父容器的,第二个是工具类加载的容器的。所以才会出现在一个事务中又起一个事务,因为容器2不知道方法已经在容器1起了一个事务,我所看到的事务没提交也是看到的容器1起的事务没提交。

如果我再仔细缕一遍全流程就会发现,dao里面还封装了一层mybatis的sqlsession,这里使用的是工具类的getBean方法。

如果再仔细看一下debug日志的话,就会发现启动应用的时候,每个xml都被加载了两次,一次是webxml的父容器,一次是工具类new加载的。

终章:结论

遇到事务失效的时候,先看一下是否被事务管理器接管了,如果有,那么多半是容器的问题,这里并不一定是父子容器,也有可能是父父容器。。

借用《黑客与画家》的一句话:如果自己就是潮水的一部分,又怎么能看见潮流的方向呢。

当遇到问题时,不要迷在某个局部,要跳出来,先把整个流程理清。

最后再说一句,开启了上帝视角之后,感觉这问题实在是很简单,不过解决过程中花费了我本人非常多时间(不少于十小时)。

希望这篇博客可以给有问题的朋友带来一点思路。