@transactional注解原理_Spring 的事务实现原理和传播机制

@transactional注解原理_Spring 的事务实现原理和传播机制

本节思维导图

 

事务管理是应用系统开发中必不可少的一部分。Spring 为事务管理提供了丰富的功能支持。Spring 事务管理分为编程式和声明式两种。编程式事务指的是通过编码方式实现事务；声明式事务基于 AOP，将具体的逻辑与事务处理解耦。生命式事务管理使业务代码逻辑不受污染，因此实际使用中声明式事务用的比较多。

声明式事务有两种方式，一种是在配置文件（XML）中做相关的事务规则声明，另一种是基于 @Transactional 注解的方式。本文着重介绍基于 @Transactional 注解的事务管理。

需要明确几点：

  • 默认配置下 Spring 只会回滚运行时、未检查异常（继承自 RuntimeException 的异常）或者 Error。

  • @Transactional 注解只能应用到 public 方法才有效。

事务的实现原理

事务的实现原理。如果说你加了一个 @Transactional 注解，此时 Spring 会使用 AOP 思想，对你的这个方法在执行之前，先去开启一个事务。执行完毕之后，根据你的方法是否报错，来决定回滚还是提交事务。

@Transactional 注解的属性介绍

下面分别介绍一下 @Transactional 的几个属性

value 和 transactionManager 属性

它们两个是一样的意思。当配置了多个事务管理器时，可以使用该属性指定选择哪个事务管理器。

isolation 属性

事务的隔离级别，默认值为 Isolation.DEFAULT。可选的值有

  • Isolation.DEFAULT：使用底层数据库默认的隔离级别

  • Isolation.READ_UNCOMMITTED：读取未提交数据（会出现脏读，不可重复读）基本不使用

  • Isolation.READ_COMMITTED：读取已提交数据（会出现不可重复读和幻读）

  • Isolation.REPEATABLE_READ：可重复读（会出现幻读）

  • Isolation.SERIALIZABLE：串行化

tip：

  • MySQL 默认为 REPEATABLE_READ 级别

  • SQL_SERVER 默认为 READ_COMMITED 级别

  • 脏读：一个事务读取到另一个事务未提交的更新数据

  • 不可重复读：同一事务中，多次读取同一数据返回的结果有所不同，即，后续读取可以读到另一事务已提交的更新数据

  • 可重复读：在同一事务中多次读取数据时，能够保证所读数据一样，也就是后续读取不能读到另一事务已提交的更新数据

  • 幻读：一个事务读到另一个事务已提交的 insert 数据。

timeout 属性

事务的超时时间，默认值为 -1。如果超过该时间限制但事务还没有完成，则自动回滚事务。

readOnly 属性

指定事务是否为只读事务，默认值为 false；为了忽略那些不需要事务的方法，比如读取数据，可以设置 read-only 为 true

rollbackFor 属性

用于指定能够触发事务回滚的异常类型，可以指定多个异常类型

noRollbackFor 属性

抛出指定的异常类型，不会滚事务，也可以指定多个异常类型

propagation 属性

事务的传播行为，默认值为 Propagation.REQUIRED。可选的值有：

  • PROPAGATION.REQUIRED：如果当前没有事务，则创建一个新事务。如果当前存在事务，就加入该事务。该设置是最常用的设置。

  • PROPAGATION.SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务。如果当前不存在事务，就以非事务执行。

  • PROPAGATION.MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常。

  • PROPAGATION.REQUIRE_NEW：创建新事务，无论当前存不存在事务，都创建新事务。

  • PROPAGATION.NOT_SUPPORTED：以非事务方式执行操作，如果当前事务存在，就把当前事务挂起。

  • PROPAGATION.NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。

  • PROPAGATION.NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则按 REQUIRED 属性执行。

@Transactional 的 propagation 属性代码示例

比如如下代码，save 方法首先调用 method1 方法，然后抛出了异常，就会导致事务回滚，如下两条数据都不会插入数据库。

@Transactional(propagation = Propagation.REQUIRED)
public void save() {
    
    method1();
    
    User user = new User("服部半藏");
    userMapper.insertSelective(user);
    
    if(true) {
        throw new RuntimeException("save 抛异常了");
    }
}
 
public void method1() {
    User user = new User("宫本武藏");
    userMapper.insertSelective(user);
}

现在有需求如下，就算 save 方法的后面抛异常了，也不能影响 method1 方法的数据插入。一般方法时给 method1 加入一个新的事务，这样 method1 就会在这个新的事务中执行，原来的事务不会影响到新的事务。例如给 method1 加 propagation 属性为 Propagation.REQUIRES_NEW 的事务。

@Transactional(propagation = Propagation.REQUIRED)
public void save() {
    
    method1();
    
    User user = new User("服部半藏");
    userMapper.insertSelective(user);
    
    if(true) {
        throw new RuntimeException("save 抛异常了");
    }
}
 
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void method1() {
    User user = new User("宫本武藏");
    userMapper.insertSelective(user);
}

运行之后，发现并没有起作用，数据也是没有插入数据库。通过查看日志发现，两个方法都是处于同一个事务中，method1 方法并没有创建一个新的事务。

 

通过 Spring 官方文档可以知道：在默认的代理模式下，只有目标方法由外部调用，才能被 Spring 的事务拦截器拦截。在同一个类中的两个方法直接调用，是不会被 Spring 的事务拦截器拦截，就像上面的 save 方法直接调用了同一个类中 method1 方法，method1 方法不会被 Spring 的事务拦截器拦截。可以使用 AspectJ 取代 Spring AOP 代理来解决这个问题。但是这里不展开。

为了解决这个问题，我们可以新建一个类：

@Service
public class OtherServiceImpl implements OtherService {
 
    @Autowired
    private UserMapper userMapper;
    
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void method1() {
        User user = new User("风魔小太郎");
        userMapper.insertSelective(user);
    }
}

然后再 save 方法中调用 otherService.method1 方法

@Autowired
private OtherService otherService;
 
@Transactional(propagation = Propagation.REQUIRED)
@Override
public void save() {
 
    otherService.method1();
 
    User user = new User("服部半藏");
    userMapper.insertSelective(user);
 
    if (true) {
        throw new RuntimeException("save 抛异常了");
    }
}

这下，otherService.method1 方法的数据插入成功，save 方法的数据未插入，事务回滚。继续查看日志：

 

从日志可以看出，首先创建了 save 方法的事务，由于 otherService.method1 方法的 @Transactional 的 propagation 属性为 Propagation.REQUIRES_NEW，所以接着暂停了 save 方法的事务，重新创建了 otherService.method1 方法的事务，接着 otherService.method1 方法的事务提交，接着 save 方法的事务回滚，这就印证了只有目标方法由外部调用，才能被 Spring 的事务拦截器拦截。

Spring 事务传播机制总结

Spring 事务传播机制总共有 7 种，其中使用最多的应该是 PROPAGATION_REQUIRES、PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED。其中所谓的嵌套事务，是指外层的事务如果回滚，会导致内层的事务也回滚；但是内层的事务如果回滚，仅仅是滚回自己的代码。

比如现在有一段业务代码，方法 A 调用方法 B，我希望的是如果方法 A 出错了，此时仅仅回滚方法 A，不能回滚方法 B，这个时候可以给方法 B 使用 REQUIRES_NEW 传播机制，让他们两的事务是不同的。

如果方法 A 调用方法 B，如果出错，方法 B 只能回滚它自己，方法 A 可以带着方法 B 一起回滚。那这种情况可以给方法 B 加上 NESTED 嵌套事务。

posted on 2023-03-22 17:18  末末随笔  阅读(247)  评论(0)  编辑  收藏  举报

导航