SpringBoot
SpringBoot

SpringBoot-事务没有生效

@Transactional 注解什么情况下会失效？

  1. 数据库引擎不支持事务
  2. @Transactional注解的方法，在类内部被调用
  3. @Transactional 应用在非 public 修饰的方法上
  4. @Transactional 注解属性 propagation 设置错误
  5. @Transactional 注解属性 rollbackFor 设置错误

  6. 异常被你的 catch“吃了”导致@Transactional失效

    本文从以上问题为切入点，简要的描述spring事务的使用方法，lets begin。

存储引擎不支持事务

我们常用的mysql数据库，提供了很多的存储引擎，可以解决不同业务场景的数据存储需求，常用的innodb是支持事务的引擎，而Myisam不支持事务。spring事务模块本身不提供事务的实现，究其原理其实是对数据库事务的封装，当数据库存储引擎没有提供事务实现，spring的事务可定也不会生效了。

在类内部调用事务方法

事务方法内部调用不生效，是动态代理的锅。注解方式配置注解，实现原理是spring aop，而spring aop 在类内部调用的时候是不进行拦截的。aop的原理是动态代理，当外部类调用切面方法时，会调用到生成的动态代理类中的增强过的方法，而类内部调用，是通过this指针调用本实例的方法。

假如方法A没有注解事务，那么在生成aop动态代理类的时候将不会对A方法进行增强。这时在A方法内部调用了事务方法B，此时会通过this指针去调用B方法，而由于A方法不是切面，调用A方法的实例是原生类的对象，this指针指向的并不是代理类，所以this中的B方法并没有被增强，因此事务不会生效。

此处需要结合spring aop的实现原理来理解，跳转

非public方法上添加事务

非public方法添加事务注解之所以会失效是因为在Spring AOP 代理时，TransactionInterceptor （事务拦截器）在目标方法执行前后进行拦截，DynamicAdvisedInterceptor（CglibAopProxy 的内部类）的 intercept 方法或 JdkDynamicAopProxy 的 invoke 方法会间接调用AbstractFallbackTransactionAttributeSource的
computeTransactionAttribute 方法，获取Transactional 注解的事务配置信息。

1
2
3
4
5
6
protected TransactionAttribute computeTransactionAttribute(Method method,
    Class<?> targetClass) {
        // Don't allow no-public methods as required.
        if (allowPublicMethodsOnly() && !Modifier.isPublic(method.getModifiers())) {
        return null;
}

此方法会检查目标方法的修饰符是否为 public，不是 public则不会获取@Transactional 的属性配置信息。

注意：protected、private 修饰的方法上使用 @Transactional 注解，虽然事务无效，但不会有任何报错，这是我们很容犯错的一点。

事务的传播级别-propagation

propagation 代表事务的传播行为，默认值为 Propagation.REQUIRED，其他的属性信息如下：

  • Propagation.NESTED ：和 Propagation.REQUIRED 效果一样。
  • Propagation.REQUIRED：如果当前存在事务，则加入该事务，如果当前不存在事务，则创建一个新的事务。( 也就是说如果A方法和B方法都添加了注解，在默认传播模式下，A方法内部调用B方法，会把两个方法的事务合并为一个事务 ）
  • Propagation.SUPPORTS：如果当前存在事务，则加入该事务；如果当前不存在事务，则以非事务的方式继续运行。
  • Propagation.MANDATORY：如果当前存在事务，则加入该事务；如果当前不存在事务，则抛出异常。
  • Propagation.REQUIRES_NEW：重新创建一个新的事务，如果当前存在事务，暂停当前的事务。( 当类A中的 a 方法用默认Propagation.REQUIRED模式，类B中的 b方法加上采用 Propagation.REQUIRES_NEW模式，然后在 a 方法中调用 b方法操作数据库，然而 a方法抛出异常后，b方法并没有进行回滚（因为此时b方法已提交），Propagation.REQUIRES_NEW会暂停 a方法的事务)
  • Propagation.NOT_SUPPORTED：以非事务的方式运行，如果当前存在事务，暂停当前的事务。
  • Propagation.NEVER：以非事务的方式运行，如果当前存在事务，则抛出异常。

若是错误的配置以下三种 propagation，事务将不会发生回滚。

  1. TransactionDefinition.PROPAGATION_SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。
  2. TransactionDefinition.PROPAGATION_NOT_SUPPORTED：以非事务方式运行，如果当前存在事务，则把当前事务挂起。
  3. TransactionDefinition.PROPAGATION_NEVER：以非事务方式运行，如果当前存在事务，则抛出异常。

事务的隔离级别-isolation

isolation ：事务的隔离级别，默认值为 Isolation.DEFAULT。

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

数据库的事务并发会带来一些问题：

脏读（读到未提交的数据）：事务A执行一条查询，事务B修改了这部分数据但没提交，导致A读取到事务B没有提交的数据，事务B可能回滚导致事务A读取到的数据是脏数据。

不可重复读：事务A执行一条查询后，事务B对这部分数据执行了update/delete并提交了，导致事务A再次查询时与上一次的查询结果不一致，称为不可重复度。

幻读：事务A执行一条范围查询后，事务B在此范围insert了若干条数据，导致事务A再次执行该查询是记录数增多，产生幻读。

注意：幻读和不可重复度的区别是事务B对数据进行的操作不同，幻读是insert操作，不可重复读是update和delete操作

以上三个问题称为数据库的读一致性问题，必须由数据库自己提供一定的事务隔离机制来解决

Isolation.READ_UNCOMMITTED 读未提交 ，没有解决以上任何问题

Isolation.READ_COMMITTED 读已提交 解决了脏读

Isolation.REPEATABLE_READ 可重复度 解决了不可重复度 innodb也解决了幻读

Isolation.SERIALIZABLE 串行化 性能巨差

事务的其他属性

timeout 属性

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

readOnly 属性

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

这里要解释一下只读事务

概念：从设置事务的时间点开始（时间点a）到这个事务结束的过程中，其他事务所提交的数据，该事务将看不见！

  • 如果执行的单条查询语句，则没有必要启用事务支持，数据库默认支持SQL执行期间的读一致性（基于MVCC）

  • 如果你一次执行多条查询语句，例如统计查询，报表查询，在这种场景下，多条查询SQL必须保证整体的读一致性，否则，在前条SQL查询之后，后条SQL查询之前，数据被其他用户改变，则该次整体的统计查询将会出现读数据不一致的状态，此时，应该启用事务支持。（spring不启用事务控制，数据库将默认为每条查询开启一个事务）

注意：在将事务设置成只读后，相当于将数据库设置成只读数据库，此时若要进行写的操作，会出现错误

rollbackFor 属性

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

rollbackFor 可以指定能够触发事务回滚的异常类型。Spring默认抛出了未检查unchecked异常（继承自 RuntimeException 的异常）或者 Error才回滚事务；其他异常不会触发回滚事务。如果在事务中抛出其他类型的异常，但却期望 Spring 能够回滚事务，就需要指定rollbackFor属性。

1
2
// 希望自定义的异常可以进行回滚
@Transactional(propagation= Propagation.REQUIRED,rollbackFor= MyException.class)

若在目标方法中抛出的异常是 rollbackFor 指定的异常的子类，事务同样会回滚。Spring源码如下：

1
2
3
4
5
6
7
8
9
private int getDepth(Class<?> exceptionClass, int depth) {
    if (exceptionClass.getName().contains(this.exceptionName)) {
        return depth;
		}
    if (exceptionClass == Throwable.class) {
        return -1;
    }
    return getDepth(exceptionClass.getSuperclass(), depth + 1);
}

如果异常被你的 catch“吃了”，会导致@Transactional失效，这种情况是最常见的一种@Transactional注解失效场景，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@Transactional
private Integer A() throws Exception {
    int insert = 0;
    try {
        CityInfoDict cityInfoDict = new CityInfoDict();
        cityInfoDict.setCityName("2");
        cityInfoDict.setParentCityId(2);
        // A 插入字段为 2的数据
        insert = cityInfoDictMapper.insert(cityInfoDict);
        // B 插入字段为 3的数据
        b.insertB();
    } catch (Exception e) {
      	e.printStackTrace();
    }
}

如果B方法内部抛了异常，而A方法此时try catch了B方法的异常，那这个事务还能正常回滚吗？

答案：不能！

会抛出异常：

1
org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only

因为当ServiceB中抛出了一个异常以后，ServiceB标识当前事务需要rollback。但是ServiceA中由于你手动的捕获这个异常并进行处理，ServiceA认为当前事务应该正常commit。此时就出现了前后不一致，也就是因为这样，抛出了UnexpectedRollbackException异常。

spring的事务是在调用业务方法之前开始的，业务方法执行完毕之后才执行commit or rollback，事务是否执行取决于是否抛出runtime异常。如果抛出runtime exception 并在你的业务方法中没有catch到的话，事务会回滚。

在业务方法中一般不需要catch异常，如果非要catch一定要抛出throw new RuntimeException()，或者注解中指定抛异常类型@Transactional(rollbackFor=Exception.class)，否则会导致事务失效，数据commit造成数据不一致，所以有些时候try catch反倒会画蛇添足。

noRollbackFor属性

noRollbackFor：抛出指定的异常类型，不回滚事务，也可以指定多个异常类型。