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

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

• 编程式事务
• 声明式事务

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

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

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

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

1. 代理生成方式

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

1. 基于接口的JDK动态代理 ：要求目标类必须实现一个接口。
2. 基于子类的CGLIB代理 ：适用于没有实现接口的目标类。

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

2. 代理不生效的情况

• 注解标注在接口方法上

  • 常见说法 ：@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在事务管理上的差异。

• 数据库本身不支持事务

  • 在某些情况下，数据库可能不支持事务。如果遇到事务不生效的问题，可以检查数据库是否支持事务。

• 未开启事务

  • 如果事务未在数据库中开启，事务管理将无法生效。

三、错误使用@Transactional导致的失效场景

• 错误的传播机制

  • Spring支持七种传播机制，其中不支持事务的传播机制有：

    • PROPAGATION_SUPPORTS
    • PROPAGATION_NOT_SUPPORTED
    • PROPAGATION_NEVER

  • 如果配置了这三种传播方式之一，在发生异常时，事务不会回滚。

• rollbackFor属性设置错误

  • rollbackFor属性用于指定哪些异常会导致事务回滚。如果设置不当，事务可能不会按预期回滚。

• 异常被内部捕获

  • 如果异常在方法内部被捕获并处理，事务管理器将无法检测到异常，从而不会触发回滚。

• 嵌套事务

  • 嵌套事务的管理较为复杂，具体效果取决于传播机制。建议在实际项目中进行充分测试。