详解在SpringBoot中@Transactional事物操作和事物无效问题排查

目录

• 1.spring事务管理简述
• 2.SpringBoot中使用@Transactional注解
• 2.1.开启事务注解
• 2.2.在目标类、方法上添加注解@Transactional
• 2.3.细化事务配置
• 3.@Transactional事务实现机制
• 3.1.整体事务控制流程
• 3.2.Spring AOP的两种代理
• 3.3.事务操作的底层实现
• 4.@Transactional使用注释实现及问题排查
• 4.1.数据库引擎是否支持事务?
• 4.3.注解所在的类是否被加载成Bean?
• 4.2.注解所在方法是否为public修饰的?
• 4.5.是否发生了自调用问题?
• 4.6.所用数据源是否加载了事务管理器?
• 4.4.触发回滚的异常是否配置正确?
• 4.5.@Transactional的扩展配置propagation是否正确?
• 4.7.事务管理的可选配置是否正确?

1.spring事务管理简述

两种事务管理方式：

1. 编码式事务管理：将事务控制代码编写在业务代码之中。
2. 声明式事务管理：基于AOP(面向切面编程)，事务管理与业务逻辑解耦。声明式事务管理的两种实现：
   1. 在配置文件(xml)中配置。
   2. 基于@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的两种代理

1. Spring AOP有两种CglibAopProxy和JdkDynamicAopProxy，其中：
2. CglibAopProxy在其内部类DynamicAdvisedInterceptor的intercept()方法中，判断是否进行事务拦截。
3. 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.
	 * <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中，关于事务的配置有两个可选配置(一般无需配置)：

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

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

到此这篇关于详解在SpringBoot中@Transactional事物操作和事物无效问题排查的文章就介绍到这了,更多相关SpringBoot使用@Transactional内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！