SpringBoot中@Transactional事务控制实现原理及事务无效问题排查

1.spring事务管理简述

两种事务管理方式：

• 编码式事务管理：将事务控制代码编写在业务代码之中。
• 声明式事务管理：基于AOP(面向切面编程)，事务管理与业务逻辑解耦。声明式事务管理的两种实现：
  • 在配置文件(xml)中配置。
  • 基于@Transactional注解。

2.SpringBoot中使用@Transactional注解

2.1.开启事务注解

在项目主类上，加上注解@EnableTransactionManagement，例如：

@EnableTransactionManagement
public class MySpringBootService extends WebMvcConfigurerAdapter {
    public static void main(String[] args) {
        SpringApplication.run(CoreService.class, args);
    }
}

2.2.在目标类、方法上添加注解@Transactional

1. 如果将@Transactional添加到类上，则表示此类的所有方法都开启事务管理。如：

   @Transactional(rollbackFor = Exception.class, propagation = Propagation.REQUIRED)
   @Service
   public class MyServiceImpl implements MyService {
     //class body
   }

2. 如果将@Transactional添加到方法上，则表示此方法开启事务管理。如：

       @Transactional(rollbackFor = Exception.class, propagation = Propagation.REQUIRES_NEW)
       @Override
       public ActivityPo getActivityById(Long id){
         //method body
       }

3. 如果一个方法上存在@Transactional，且其所属类上同样存在@Transactional，则以方法级别的事务配置为准。

2.3.细化事务配置

关于@Transactional的可配置参数有很多，主要有propagation、rollbackFor等，可以适用于不同场景，这里不细说。

3.@Transactional事务实现机制

3.1.整体事务控制流程

1. 当@Transactional注解的方法被类外部的代码调用时，Spring在运行时为方法所在类生成一个AOP代理对象。
2. 代理对象根据@Transactional的属性，决定是否由事务拦截器TransactionInterceptor对此方法进行事务拦截。
3. 在进行事务拦截时，会先开启事务，然后执行业务代码，根据执行是否出现异常，通过抽象事务管理器AbstractPlatformTransactionManager来进行rollback或者commit。

3.2.Spring AOP的两种代理

Spring AOP有两种CglibAopProxy和JdkDynamicAopProxy，其中：

1. CglibAopProxy在其内部类DynamicAdvisedInterceptor的intercept()方法中，判断是否进行事务拦截。

2. JdkDynamicAopProxy在其invoke()方法中，判断是否进行事务拦截。

3.3.事务操作的底层实现

1. 抽象事务管理器AbstractPlatformTransactionManager的rollback和commit都需要具体的实现类进行实现。

2. 抽象事务管理器AbstractPlatformTransactionManager的父级接口是PlatformTransactionManager。

3. 存在很多事务管理器实现类，例如DataSourceTransactionManager等。

4. 不同的事务管理器管理不同的数据资源 DataSource，比如DataSourceTransactionManager管理者JDBC数据源。

5. 应确保被调用方法中使用的数据源都加载了事务管理器。

4.@Transactional使用注释实现及问题排查

4.1.数据库引擎是否支持事务?

• MySql的引擎MyIsam不支持事务。
• 如需事务控制生效，则库和表的引擎必须是InnoDB。

4.3.注解所在的类是否被加载成Bean?

• 章节3.1中第1条提到，需要在运行时为类生成代理对象。那么前提是这个类一定被Spring管理并加载成了一个Bean对象。
• 确保所在类是否被@Component、@Service、@Controller等等注解注释。

4.2.注解所在方法是否为public修饰的?

• 章节3.2中，提到两种AOP代理分别在intercept()和invoke()方法判断是否进行事务拦截。
• 这两个方法都会间接调用AbstractFallbackTransactionAttributeSource类的computeTransactionAttribute方法来获取事务控制的相关属性。这其中有以下一段代码：

	/**
	 * Same signature as {@link #getTransactionAttribute}, but doesn't cache the result.
	 * {@link #getTransactionAttribute} is effectively a caching decorator for this method.
	 * 
As of 4.1.8, this method can be overridden.
	 * @since 4.1.8
	 * @see #getTransactionAttribute
	 */
	protected TransactionAttribute computeTransactionAttribute(Method method, Class<?> targetClass) {
		// Don't allow no-public methods as required.
		if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {
			return null;
		}
    
    //...
  }

• 这段代码会导致no-public的方法无法进入事务控制。

• 所以，一定要确保自己需要进行事务控制的方法包含public修饰符。

4.5.是否发生了自调用问题?

• 章节3.1中第1条强调：只有当事务方法被当前类以外的代码调用时，才会才由 Spring 生成的代理对象来管理。

• 上述逻辑会造成自调用问题：当事务方法被本类内部方法调用时，@Transactional并不生效。

• 自调用示例代码：

  @Service
  public class PersonServiceImpl implements PersonService{
    @Resource
    private PersonDao personDao;
    
    public void insertPerson(Person person){
      //自调用
      personService.insert(person);
      
      //其他代码
      personDao.insertLog...
  	}
    
    @Transactional(rollbackFor = Exception.class)
    public void insert(Person person){
      personDao.insert(person);
  	}
  }
  

• 上述代码中，如果业务逻辑从非事务方法insertPerson()开始，在其中调用了事务方法insert()，则当insert()异常时，事务控制无效。

• 简单说，就是在同一类中，非事务方法A调用了事务方法B，则当事务方法B异常，事务控制无效，A和B都不会回滚。

• 那么，在同一类中，事务方法A调用了非事务方法B，然后非事务方法B调用了事务方法C，事务是否生效？答案：是。因为事务方法A在被外部代码调用时，已经开启了事务管理。

4.6.所用数据源是否加载了事务管理器?

• 章节3.3中第5条提到：应确保被调用方法中使用的数据源都加载了事务管理器。

• 在SpringBoot项目中，如果是单数据源，那么系统会默认为单数据源配置事务管理器DataSourceTransactionManager。

• 在SpringBoot项目中，如果是多数据源，则一定确保所有的数据源都配置了事务管理器。

• 关于多数据源的配置方法可以参考: https://blog.csdn.net/hanchao5272/article/details/81209552

• 事务管理器的手动配置方法，可以参考如下：

  @Bean
  @Primary
  public PlatformTransactionManager primaryTransactionManager(@Qualifier("sqlDataSource") DataSource sqlDataSource) {
    return new DataSourceTransactionManager(sqlDataSource);
  }
  

4.4.触发回滚的异常是否配置正确?

• 默认情况下，事务回归针对的是uncheck的异常(运行时异常)或ERROR。

• 默认情况下，check的异常并不会触发回滚，如FileNotFoundException。

• 如果想要简单的配置成针对所有异常都回滚，可以这么做：

  @Transactional(rollbackFor = Exception.class)
  

4.5.@Transactional的扩展配置propagation是否正确?

• 一般情况下，propagation属性无需配置。其会使用默认配置，即：Propagation.REQUIRED。
• 有些propagation属性会导致事务不会触发，一定要注意：
  • SUPPORTS: 如果存在事务，则进入事务；否则，以非事务方式运行。
  • NOT_SUPPORTED: 如果存在事务，则挂起事务，并以非事务方式运行。
  • NEVER: 以非事务形式运行，如果存在事务，则抛出异常。

4.7.事务管理的可选配置是否正确?

在SpringBoot中，关于事务的配置有两个可选配置(一般无需配置)：

1. Springboot启动类的@EnableTransactionManagement。

2. Springboot配置文件的rollback-on-commit-failure属性：

   # yaml配置
   spring:
     transaction:
       rollback-on-commit-failure: true
       
   # properties配置
   spring.transaction.rollback-on-commit-failure=true
   

请确保上述配置都是正确的(或者未配置)。