记一次Spring Transactional注解事务失效问题定位

背景

     平台功能，有插入数据部分丢失的情况；经初步定位是因为多次入库操作没有在一个事务内进行

解决过程

     利用Spring transactional注解对service中操作入库的操作方法添加注解；添加完成之后，测试发现，事务没有生效。what？

然后进行事务没有生效的原因定位；

1、检查事务的传播方式，项目默认的传播行为；

     项目的默认传播行为，PROPAGATION_REQUIRED，符合业务应用场景

2、经排查发现，有部分方法异常被catch住，没有把异常抛出，导致不能检查异常，从而不会回滚

     修改方法，把捕获的异常重新抛出；测试发现，异常抛出后，事务仍然没有生效，抛出异常后 ，DB依然没有回滚，什么情况？继续排查

3、@Transactional 只对 public修饰上生效，其他修饰不起作用

     排查，没有问题，所有的注解的方法都是public方法

4、默认情况下此注解会对unchecked异常进行回滚，对checked异常不回滚。

       所有如果想要对checked异常也进行事务回滚，需要制定transactional 回滚类型 rollback = Exception.class;  这样，会对捕获的所有异常都进行回滚；实测，依然不生效，此时，我心态有点不好了，哈哈，但是依然没有放弃

5、 查看了一下配置文件，发现

   proxy-target-class 竟然设置成了false？这是谁干的？出来，我要打人！因为我们的平台都是基于类代理的，没有接口代理的情况，所以，我把proxy-target-class="false" 修改成proxy-target-class="true"，我想，现在肯定没问题了；测试，我靠，事务还是不生效；整个人已经很不好了

6、配置多个数据源的事务问题

     后来只能单步调试，调试中发现TransactionManager并不是我们定义的；原因终于找到了；原来是项目中用到了多个数据源，而配置多个数据源，事务会以加载的第一个数据源为准；注解中用到的事务，默认都是生效在第一个数据源

解决方案：注解@Transactional时，如果指定默认事务处理器

指定之后默认事务处理器之后，事务总算是生效了；被一个很简单的配置问题，搞得焦头烂额，最后总算是解决了，还是很开心的；