声明式事务@Transactional失效场景研究

Spring为了更好地支持数据库操作，在框架中提供了两种事务管理方式：

本文主要探讨声明式事务的失效场景，假设读者已经熟悉声明式事务的基本用法及其作用。

重要提示：Spring仅负责事务的编程管理，最终的数据事务仍由数据库实现。

一、代理不生效导致的失效场景

Spring中对注解的解析基于代理机制。如果目标方法无法被Spring代理到，事务管理将无法生效。

Spring生成代理的方式主要有两种：

在Spring 2.0之前，如果目标类实现了接口，则使用JDK动态代理；否则使用CGLIB代理。从2.0版本开始，默认使用CGLIB代理，除非在配置文件中显式指定spring.aop.proxy-target-class=false。

注解标注在接口方法上
- 常见说法 ：@Transactional注解只能标注在类或方法上，如果标注在接口方法上，CGLIB代理将无法解析到该注解，导致事务失效。
- 实际测试结果 ：注解标注在接口方法上，事务仍然生效，前提是该方法是事务的入口方法，并且是由Spring Bean调用的。
被final或static修饰的类或方法
- 常见说法 ：CGLIB通过生成目标类的子类来创建代理，因此被final或static修饰的类或方法无法被代理。
- 实际测试结果 ：
  - 被final修饰的方法，事务仍然生效。
  - 被static修饰的方法，由于静态方法属于类而不是实例，无法通过Spring Bean调用，因此声明式事务无效。
类方法内部调用
- 常见说法 ：事务管理通过代理执行，如果方法内部调用，不会走代理逻辑，导致事务失效。
- 实际测试结果 ：方法内部调用，事务仍然生效，前提是该方法是事务的入口方法，并且是由Spring Bean调用的。
当前类没有被Spring管理
- 如果类没有被Spring管理成为IOC容器中的一个Bean，事务切面将无法生效。新手常犯的错误是混淆了Spring管理的Bean和通过new关键字创建的实例。

这些场景主要集中在Spring框架在解析@Transactional时的内部支持。如果使用的场景本身不受框架支持，事务将无法生效。

非public修饰的方法
- 常见说法 ：非public方法上添加@Transactional注解不会生效。
- 实际测试结果 ：非public方法上，事务仍然生效。
多线程调用
- 事务信息与线程绑定，因此在多线程环境中，每个线程的事务信息是独立的，可能导致Spring在事务管理上的差异。
数据库本身不支持事务
- 在某些情况下，数据库可能不支持事务。如果遇到事务不生效的问题，可以检查数据库是否支持事务。
未开启事务
- 如果事务未在数据库中开启，事务管理将无法生效。

错误的传播机制
- Spring支持七种传播机制，其中不支持事务的传播机制有：
  - PROPAGATION_SUPPORTS
  - PROPAGATION_NOT_SUPPORTED
  - PROPAGATION_NEVER
- 如果配置了这三种传播方式之一，在发生异常时，事务不会回滚。
rollbackFor属性设置错误
- rollbackFor属性用于指定哪些异常会导致事务回滚。如果设置不当，事务可能不会按预期回滚。
异常被内部捕获
- 如果异常在方法内部被捕获并处理，事务管理器将无法检测到异常，从而不会触发回滚。
嵌套事务
- 嵌套事务的管理较为复杂，具体效果取决于传播机制。建议在实际项目中进行充分测试。