spring 事务失效的几种场景

一、背景

在 springBoot 开发过程中，我们一般都是在业务方法上添加 @Transactional 注解来让 spring 替我们管理事务，但在某些特定的场景下，添加完注解之后，事务是不生效的，接下来详细介绍下。

二、方法不是 public

2.1 场景描述

当添加 @Transactional 注解的方法不是 public 类型的，事务会失效。如下代码：

@Transactional
private void someTransactionalMethod() {// 业务逻辑
}

2.2 原因分析

在 Spring 中，只有 public 方法才能被 AOP 代理处理，因此如果 @Transactional 注解的方法不是 public 的，事务管理将失效。

2.3 解决方案

确保 @Transactional 注解的方法是 public。如下：

@Transactional
public void someTransactionalMethod() {// 业务逻辑
}

三、方法内部调用

3.1 场景描述

当一个类内部的方法调用另一个标注了 @Transactional 的方法时，事务管理将失效。如下代码：

@Service
public class MyServiceImpl {public void outerMethod() {publicMethod();}	@Transactionalpublic void publicMethod() {// 业务逻辑}
}

3.2 原因分析

这是因为内部方法方法的调用没有经过代理类，即在 outerMethod() 方法里面调用的 publicMethod() 方法是 MyServiceImpl 对象调用的，并不是经过 spring 代理类来调用的，所以事务会失效。

3.3 解决方案

解决方案就是通过代理对象方法调用，使用 AOP 代理进行事务管理，如下代码：

@Service
public class MyServiceImpl {public void outerMethod() {// 通过代理对象调用 publicMethod((MyServiceImpl) AopContext.currentProxy()).publicMethod();}	@Transactionalpublic void publicMethod() {// 业务逻辑}
}

四、未被 spring 管理

4.1 场景描述

当一个类没有被 spring 管理时，事务不会生效，如下代码：

public class MyServiceImpl {@Transactionalpublic void someTransactionalMethod() {// 业务逻辑}
}

4.2 原因分析

只有在 Spring 容器中管理的 bean，才能被 AOP 代理。如果 @Transactional 注解的方法所在的类没有被 Spring 管理，事务管理将失效。

4.3 解决方案

确保类被 Spring 容器管理，如通过 @Service，@Component 等注解。

@Service
public class MyServiceImpl {@Transactionalpublic void someTransactionalMethod() {// 业务逻辑}
}

五、方法用 final 或 static 修饰

5.1 场景描述

有时候，某个方法不想被子类重写，这时可以将该方法定义成 final 的。普通方法这样定义是没问题的，但如果将事务方法定义成 final，那么事务将会失效。

@Service
public class UserService {@Transactionalpublic final void add(UserModel userModel){saveData(userModel);updateData(userModel);}
}

5.2 原因分析

spring 事务底层使用了 aop，也就是通过 jdk 动态代理或者 cglib，帮我们生成了代理类，在代理类中实现的事务功能。但如果某个方法用 final 修饰了，那么在它的代理类中，就无法重写该方法，而添加事务功能。

注意：如果某个方法是 static 的，同样无法通过动态代理，变成事务方法。

5.3 解决方案

不使用 final 或者 static 修饰方法，如下：

@Service
public class UserService {@Transactionalpublic void add(UserModel userModel){saveData(userModel);updateData(userModel);}
}

六、配置不当

6.1 场景描述

@Transactional 注解的一些配置属性，可能会影响事务的行为，如下代码：

@Transactional(readOnly = true) 
public void someTransactionalMethod() {// 业务逻辑
}

6.2 原因分析

配置了 readOnly=true 属性，那么执行增删改操作时就会报错。因为这个属性指定了此方法只能进行读操作。

6.3 解决方案

检查配置的具体含义，确保其适当应用。

@Transactional(readOnly = false) 
public void someTransactionalMethod() {// 业务逻辑
}

七、多线程调用

7.1 场景描述

spring 事务在多线程场景下，会有问题，如下代码

@Service
public class UserService {@Autowiredprivate UserMapper userMapper;@Autowiredprivate RoleService roleService;@Transactionalpublic void add(UserModel userModel) throws Exception {userMapper.insertUser(userModel);new Thread(() -> {roleService.doOtherThing();}).start();}
}@Service
public class RoleService {@Transactionalpublic void doOtherThing() {System.out.println("保存role表数据");}
}

7.2 原因分析

从上面的例子中，我们可以看到事务方法 add 中，调用了事务方法 doOtherThing，但是事务方法 doOtherThing 是在另外一个线程中调用的。

这样会导致两个方法不在同一个线程中，获取到的数据库连接不一样，从而是两个不同的事务。如果将来 doOtherThing 方法中抛了异常，add 方法也回滚是不可能的。

如果看过 spring 事务源码的朋友，可能会知道 spring 的事务是通过数据库连接来实现的。当前线程中保存了一个 map，key 是数据源，value 是数据库连接。

我们说的同一个事务，其实是指同一个数据库连接，只有拥有同一个数据库连接才能同时提交和回滚。如果在不同的线程，拿到的数据库连接肯定是不一样的，所以是不同的事务。

7.3 解决方案

避免在多线程中使用 @Transactional，或者手动管理线程间的事务。

@Service
public class MyService {@Transactionalpublic void someTransactionalMethod() {ExecutorService executorService = Executors.newSingleThreadExecutor();executorService.submit(() -> {// 手动管理事务TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());try {// 业务逻辑transactionManager.commit(status);} catch (Exception e) {transactionManager.rollback(status);throw e;}});}
}

八、错误的传播特性

8.1 场景描述

如果我们在手动设置 propagation 参数的时候，把传播特性设置错了，事务可能就不会生效，如下代码：

@Service
public class UserService {@Transactional(propagation = Propagation.NEVER)public void add(UserModel userModel) {saveData(userModel);updateData(userModel);}
}

8.2 原因分析

propagation 参数的作用是指定事务的传播特性，spring 目前支持 7 种传播特性：

EQUIRED：如果当前上下文中存在事务，则加入该事务，如果不存在事务，则创建一个事务，这是默认的传播属性值。

SUPPORTS：如果当前上下文中存在事务，则支持事务加入事务，如果不存在事务，则使用非事务的方式执行。

MANDATORY：当前上下文中必须存在事务，否则抛出异常。

REQUIRES_NEW：每次都会新建一个事务，并且同时将上下文中的事务挂起，执行当前新建事务完成以后，上下文事务恢复再执行。

NOT_SUPPORTED：如果当前上下文中存在事务，则挂起当前事务，然后新的方法在没有事务的环境中执行。

NEVER：如果当前上下文中存在事务，则抛出异常，否则在无事务环境上执行代码。

NESTED：如果当前上下文中存在事务，则嵌套事务执行，如果不存在事务，则新建事务。

我们可以看到 add 方法的事务传播特性定义成了 Propagation.NEVER，这种类型的传播特性不支持事务，如果有事务则会抛异常。

8.3 解决方案

目前只有这三种传播特性才会创建新事务：REQUIRED，REQUIRES_NEW，NESTED。

@Service
public class UserService {@Transactional(propagation = Propagation.REQUIRED)public void add(UserModel userModel) {saveData(userModel);updateData(userModel);}
}

九、自己吞了异常

8.1 场景描述

开发者在代码中手动 try...catch 了异常，事务不会生效，如下代码：

@Slf4j
@Service
public class UserService {@Transactionalpublic void add(UserModel userModel) {try {saveData(userModel);updateData(userModel);} catch (Exception e) {log.error(e.getMessage(), e);}}
}

8.2 原因分析

这种情况下 spring 事务当然不会回滚，因为开发者自己捕获了异常，又没有手动抛出，换句话说就是把异常吞掉了。

8.3 解决方案

如果想要 spring 事务能够正常回滚，必须抛出它能够处理的异常。如果没有抛异常，则 spring 认为程序是正常的。如下代码：

@Slf4j
@Service
public class UserService {@Transactionalpublic void add(UserModel userModel)throws Exception {saveData(userModel);updateData(userModel);}
}

十、手动抛了别的异常

8.1 场景描述

即使开发者没有手动捕获异常，但如果抛的异常不正确，spring 事务也不会回滚。如下代码：

@Slf4j
@Service
public class UserService {@Transactionalpublic void add(UserModel userModel) throws Exception {try {saveData(userModel);updateData(userModel);} catch (Exception e) {log.error(e.getMessage(), e);throw new Exception(e);}}
}

8.2 原因分析

上面的这种情况，开发人员自己捕获了异常，又手动抛出了异常：Exception，事务同样不会回滚。

因为 spring 事务，默认情况下只会回滚 RuntimeException（运行时异常）和 Error（错误），对于普通的 Exception（非运行时异常），它不会回滚。

8.3 解决方案

别采取这种写法。

十一、自定义了回滚异常

11.1 场景描述

在使用 @Transactional 注解声明事务时，有时我们想自定义回滚的异常，spring 也是支持的。可以通过设置 rollbackFor 参数，来完成这个功能。但如果这个参数的值设置错了，就会引出一些莫名其妙的问题，如下代码：

@Slf4j
@Service
public class UserService {@Transactional(rollbackFor = BusinessException.class)public void add(UserModel userModel) throws Exception {saveData(userModel);updateData(userModel);}
}

11.2 原因分析

如果在执行上面这段代码，保存和更新数据时，程序报错了，抛了 SqlException、DuplicateKeyException 等异常。而 BusinessException 是我们自定义的异常，报错的异常不属于 BusinessException，所以事务也不会回滚。

即使 rollbackFor 有默认值，但阿里巴巴开发者规范中，还是要求开发者重新指定该参数。