@Transactional失效的场景都有哪些呢？
如图所示！
以上我们列举了10种场景，接下来我们针对不同的场景来具体的分析下。
一、代理不生效导致
1、同一个类中，方法内部调用事务失效
同一个类中，addOrder()方法无事务，addOrder2()方法存在事务，addOrder()调用addOrder2()。
我们通过外部方法调用addOrder()方法，来完成数据库的插入，通过手动的设置异常order/0，来观察addOrder2()方法中的数据是否会正常回滚。
通过数据库的结果显示，数据正常入库了，证明了我们的事务并未生效。
同一个类中，addOrder()和addOrder2()都存在事务，addOrder()调用addOrder2()。
order/0 产生异常之后，通过数据库的结果显示，发现数据并未入库，说明事务生效了。
我们发现并不是所有同一个类，方法的内部调用事务都会失效。
那我们就来了解一下事务为啥不生效？
看图 ！外部代码调用addOrder()方法时，并没有直接进入目标方法，而是首先进入了DynamicAdvisedInterceptor的intercept()方法中。
这是因为我们的orderService的bean在项目在项目启动的时候就生成一个代理对象，这里调用addOrder()方法的，其实是代理对象，而代理对象对目标方法的调用，会转发进入CGLIB动态代理类的intercept()方法中进行增强。
在方法调用栈中，我们发现了TransactionInterceptor事务拦截器。
而通过TransactionInterceptor 这个机制，我们完成了对目标方法的增强，例如事务控制，主要处理逻辑在TransactionAspectSupport.invokeWithinTransation()中。
只有当调用addOrder2()方法是通过代理类进行的时候，才能触发事务的拦截。
2、事务方法被final、static修饰
示例代码：
失效原因：CGLIB是通过生成目标类子类的方式生成代理类的，被final、static修饰的方法，无法被子类重写。
3、当前类没有被Spring管理
例如：Service类中没有@Service注解
public class OrderServiceImpl {
@Autowired
private OrderMapper orderMapper;
@Transactional
public int addOrder(Double amount, String address) {
int order = orderMapper.addOrder(amount, address);
int i = order / 0;
return order;
}
}从以上的两种场景分析，我们得知@Transactional事务生效的前提条件是需要代理类对目标方法的调用，才能触发事务处理，如果我们的类没有@Service注解，就不会交给spring容器初始化处理，也就无法为目标类生成代理类。
二、框架或者底层不支持
4、非public修饰的方法（存在版本差异）
示例代码：
通过外部接口的调用，异常之后，发现事务正常回滚，数据库数据并没有入库，说明事务是生效的。
springframework的版本：6.0.11
不是说非public修饰的方法，事务不生效吗？
通过本地debug分析源码得知，在spring版本6.0.11中是支持proected修饰的方法的。
对比了spring5.3.25的版本，发现之前的版本，publicMethodOnly默认值确实为true。
5、事务多线程调用
示例代码：
当我们使用外部接口调用addOrder()方法时，sysUserService.saveUser()方法发生异常。但是发现orderMapper.addOrder()的数据正常入库了，事务失效。
通过本地debug和分析源码得知，我们的事务是给线程绑定的（TransactionAspectSupport.prepareTransactionInfo()）。
在执行sysUserService.saveUser()目标方法的时候，我们通过代理类执行逻辑，获取到的事务AbstractPlatformTransactionManager.getTransaction()其实是重新创建的一个事务。
因此当saveUser()方法发生异常时，addOrder()方法的事务未能同步回滚数据。
6、数据库本身不支持事务
三、开发使用不当引发
7、异常被方法内部try catch捕获，没有重新抛出
示例代码：
当外部接口调用addOrder()方法，异常发生的时候，数据库数据正常入库了，事务未生效。
在TransactionAspectSupport.invokeWithinTransaction()方法中，我们可以看到以下逻辑。
8、嵌套事务回滚多了
示例代码：
9、rollbackFor属性设置错误
示例代码：
@Service
public class OrderServiceImpl {
@Autowired
private OrderMapper orderMapper;
@Transactional
public int addOrder(Double amount, String address) throws FileNotFoundException {
int order = orderMapper.addOrder(amount, address);
throw new FileNotFoundException("11111");
}
}在demo中，我们手动的抛出FileNotFountException异常，这是一个IOException异常。
当我们使用@Transactional，在未对rollbackFor做配置的情况下，默认是支持对Runtime和Error异常的回滚的。
但当我们的demo中的异常是IOException的时候
从源码694行else逻辑的注释上我们也能看出，无法回滚异常。
所以通常情况下，我们建议指定@Transactional(rollbackFor = Exception.class)的方式进行异常捕获。
10、设置不支持事务的传播机制
Spring支持了7种传播机制，分别为：
上面不支持事务的传播机制为：PROPAGATION_SUPPORTS，PROPAGATION_NOT_SUPPORTED，PROPAGATION_NEVER。
如果配置了这三种传播方式的话，在发生异常的时候，事务是不会回滚的。
示例代码：
@Service
public class OrderServiceImpl {
@Autowired
private OrderMapper orderMapper;
@Transactional(rollbackFor = Exception.class, propagation = Propagation.SUPPORTS)
public int addOrder(Double amount, String address) throws FileNotFoundException {
int order = orderMapper.addOrder(amount, address);
throw new FileNotFoundException("11111");
}
}
在处理事务异常回滚AbstractPlatformTransactionManager.processRollback()的逻辑中，这三种传播机制，就只是打印了下debug日志，没有进行真正的回滚，从日志记录信息中我们可以看到：
logger.debug("Should roll back transaction but cannot - no transaction available");
应该回滚但是不能，因为没有可用的事务。
最后说一句(求关注!别白嫖！)
如果这篇文章对您有所帮助，或者有所启发的话，求一键三连：点赞、转发、在看。
关注公众号：woniuxgg，在公众号中回复：笔记 就可以获得蜗牛为你精心准备的java实战语雀笔记，回复面试、开发手册、有超赞的粉丝福利！
