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

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

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

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

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

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

2.3.细化事务配置

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

3.@Transactional事务实现机制

3.1.整体事务控制流程

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

3.2.Spring AOP的两种代理

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

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

3.3.事务操作的底层实现

抽象事务管理器AbstractPlatformTransactionManager的rollback和commit都需要具体的实现类进行实现。
抽象事务管理器AbstractPlatformTransactionManager的父级接口是PlatformTransactionManager。
存在很多事务管理器实现类，例如DataSourceTransactionManager等。
不同的事务管理器管理不同的数据资源 DataSource，比如DataSourceTransactionManager管理者JDBC数据源。
应确保被调用方法中使用的数据源都加载了事务管理器。

扫描二维码关注公众号，回复： 6494994 查看本文章

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.
	 * <p>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中，关于事务的配置有两个可选配置(一般无需配置)：

Springboot启动类的@EnableTransactionManagement。

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

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

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