springboot 事务 抛出异常_SpringBoot2异常处理回滚事务详解(自动回滚/手动回滚/部分回滚...

1 问题背景

有时候，我们总是需要再SpringBoot2中对一个Service方法做一个完整的事务，发现异常时，进行回滚，然后又能返回错误信息。

事务定义

事务，就是一组操作数据库的动作集合。事务是现代数据库理论中的核心概念之一。如果一组处理步骤或者全部发生或者一步也不执行，我们称该组处理步骤为一个事务。当所有的步骤像一个操作一样被完整地执行，我们称该事务被提交。由于其中的一部分或多步执行失败，导致没有步骤被提交，则事务必须回滚到最初的系统状态。

事务特点

1.原子性：一个事务中所有对数据库的操作是一个不可分割的操作序列，要么全做要么全不做

2.一致性：数据不会因为事务的执行而遭到破坏

3.隔离性：一个事物的执行，不受其他事务的干扰，即并发执行的事物之间互不干扰

4.持久性：一个事物一旦提交，它对数据库的改变就是永久的。

2 @Transactional 事务实现机制

Spring 为事务管理提供了丰富的功能支持。Spring 事务管理分为编码式和声明式的两种方式。

(1)编程式事务指的是通过编码方式实现事务；

(2)声明式事务基于 AOP,将具体业务逻辑与事务处理解耦。

声明式事务管理使业务代码逻辑不受污染, 因此在实际使用中声明式事务用的比较多。

声明式事务有两种方式：

(1)一种是在配置文件(xml)中做相关的事务规则声明，

(2)另一种是基于@Transactional 注解的方式。

注释配置是目前流行的使用方式，因此本文将着重介绍基于@Transactional 注解的事务管理。

在应用系统调用声明了 @Transactional 的目标方法时，Spring Framework 默认使用 AOP 代理，在代码运行时生成一个代理对象，根据 @Transactional 的属性配置信息，这个代理对象决定该声明 @Transactional 的目标方法是否由拦截器 TransactionInterceptor 来使用拦截，在 TransactionInterceptor 拦截时，会在目标方法开始执行之前创建并加入事务，并执行目标方法的逻辑, 最后根据执行情况是否出现异常，利用抽象事务管理器 AbstractPlatformTransactionManager 操作数据源 DataSource 提交或回滚事务。

Spring AOP 代理有 CglibAopProxy 和 JdkDynamicAopProxy 两种，以 CglibAopProxy 为例，对于 CglibAopProxy，需要调用其内部类的 DynamicAdvisedInterceptor 的 intercept 方法。对于 JdkDynamicAopProxy，需要调用其 invoke 方法。

开启事务

方式1：在 xml 配置中的事务配置信息

class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

方式2：使用@EnableTransactionManagement 注解也可以启用事务管理功能

3 场景

3.1 场景一：自动回滚(直接抛出，不try/catch)

@Override

@Transactional(rollbackFor = Exception.class)

public Object submitOrder() throws Exception {

success();

//假如exception这个操作数据库的方法会抛出异常，方法success()对数据库的操作会回滚。

exception();

return ApiReturnUtil.success();

}

3.2 场景二：手动回滚(进行try/catch，回滚并抛出)

@Override

@Transactional(rollbackFor = Exception.class)

public Object submitOrder (){

success();

try {

exception();

} catch (Exception e) {

e.printStackTrace();

//手工回滚异常

TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

return ApiReturnUtil.error();

}

return ApiReturnUtil.success();

}

3.3 补充：回滚部分异常

使用Object savePoint = TransactionAspectSupport.currentTransactionStatus().createSavepoint(); 设置回滚点。

使用TransactionAspectSupport.currentTransactionStatus().rollbackToSavepoint(savePoint);回滚到savePoint。

@Override

@Transactional(rollbackFor = Exception.class)

public Object submitOrder (){

success();

//只回滚以下异常，

Object savePoint = TransactionAspectSupport.currentTransactionStatus().createSavepoint();

try {

exception();

} catch (Exception e) {

e.printStackTrace();

//手工回滚异常

TransactionAspectSupport.currentTransactionStatus().rollbackToSavepoint(savePoint);

return ApiReturnUtil.error();

}

return ApiReturnUtil.success();

}

3.4 使用DataSourceTransactionManager

springboot 开启事务以及手动提交事务，可以在服务类上加上两个注解

@Autowired

DataSourceTransactionManager dataSourceTransactionManager;

@Autowired

TransactionDefinition transactionDefinition;

手动开启事务

TransactionStatus transactionStatus = dataSourceTransactionManager.getTransaction(transactionDefinition);

手动提交事务

dataSourceTransactionManager.commit(transactionStatus);//提交

手动回滚事务

dataSourceTransactionManager.rollback(transactionStatus);//最好是放在catch 里面,防止程序异常而事务一直卡在哪里未提交

4 spring boot controller设置 @Transactional 不回滚的解决办法

在spring boot 中，使用事务非常简单，直接在方法上面加入@Transactional 就可以实现，以下是我的做法

@GetMapping("delete")

@ResponseBody

@Transactional

public void delete(@RequestParam("id") int id) {

try {

//delete country

this.repository.delete(id);

if(id == 1){

throw Exception("测试事务");

}

//delete city

this.repository.deleteByCountryId(id);

}catch (Exception e){

logger.error("delete false:" + e.getMessage());

return new MessageBean(101,"delete false");

}

}

发现事务不回滚，即 this.repository.delete(id); 成功把数据删除了。

原因：

默认spring事务只在发生未被捕获的 RuntimeException 时才回滚。

spring aop  异常捕获原理：被拦截的方法需显式抛出异常，并不能经任何处理，这样aop代理才能捕获到方法的异常，才能进行回滚，默认情况下aop只捕获 RuntimeException 的异常，但可以通过配置来捕获特定的异常并回滚。

换句话说在service的方法中不使用try catch 或者在catch中最后加上throw new runtimeexcetpion()，这样程序异常时才能被aop捕获进而回滚。

解决方案：

方案1：例如service层处理事务，那么service中的方法中不做异常捕获，或者在catch语句中最后增加throw new RuntimeException()语句，以便让aop捕获异常再去回滚，并且在service上层(webservice客户端，view层action)要继续捕获这个异常并处理

方案2：在service层方法的catch语句中增加：TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();语句，手动回滚，这样上层就无需去处理异常

@GetMapping("delete")

@ResponseBody

@Transactional

public Object delete(@RequestParam("id") int id){

if (id < 1){

return new MessageBean(101,"parameter wrong: id = " + id) ;

}

try {

//delete country

this.countryRepository.delete(id);

//delete city

this.cityRepository.deleteByCountryId(id);

return new MessageBean(200,"delete success");

}catch (Exception e){

logger.error("delete false:" + e.getMessage());

TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

return new MessageBean(101,"delete false");

}

}

5 避免 Spring 的 AOP 的自调用问题

在 Spring 的 AOP 代理下，只有目标方法由外部调用，目标方法才由 Spring 生成的代理对象来管理，这会造成自调用问题。若同一类中的其他没有@Transactional 注解的方法内部调用有@Transactional 注解的方法，有@Transactional 注解的方法的事务被忽略，不会发生回滚。见清单 5 举例代码展示。

清单 5.自调用问题举例

@Service

public class OrderService {

private void insert() {

insertOrder();

}

@Transactional

public void insertOrder() {

//insert log info

//insertOrder

//updateAccount

}

}

insertOrder 尽管有@Transactional 注解，但它被内部方法 insert()调用，事务被忽略，出现异常事务不会发生回滚。

这样一个错org.springframework.transaction.NoTransactionException: No transaction aspect-managed TransactionStatus in scope

比如例子:

下面我们来看两种写法，第一种

@Transactional

public UserEntity login1(UserEntity user) {

userDao.update(6);

if(userDao.update(6)){

TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

}

return user;

}

第二种

public UserEntity login(UserEntity user) {

this.test();

return user;

}

@Transactional

public void test(){

userDao.update(6);

if(userDao.update(6)){

TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

}

}

第一种写法的时候，回滚是起作用的.

第二种写法的时候就会报错，错误就是一开始提到的: org.springframework.transaction.NoTransactionException: No transaction aspect-managed TransactionStatus in scope

为什么会这样呢？

此错在没有Transaction无法回滚事务。自调用导致@Transactional 失效。

spring里事务是用注解配置的，当一个方法没有接口，单单只是一个方法不是服务时，事务的注解是不起作用的，需要回滚时就会报错。

出现这个问题的根本原因在于AOP的实现原理。由于@Transactional 的实现原理是AOP，AOP的实现原理是动态代理，换句话说，自调用时不存在代理对象的调用，这时不会产生我们注解@Transactional 配置的参数，自然无效了。

虽然可以直接从容器中获取代理对象，但这样有侵入之嫌，不推荐。

也是在此记录一笔：

事务必须用在服务上，且一个服务一个事务，不得嵌套。

sping的事务是通过注解配置上去的，而下面的那个方法并没有接口，在实现类里面只是一个简单的方法而已，对于事务的注解来说没有任何作用，所以在这个方法里面调用回滚的方法自然就报错了。

所以在以后的项目中如果你要使用事务，那么请记住，一个服务一个事务，一次请求一个事务，千万不要想着用调用方法，然后再一个方法上面加事务。你只能调用另外一个服务，在另外一个服务上面加事务。

解决方法：

1、可以在类服务上加事务：

@Transactional

public class MyTransactional {

public UserEntity login(UserEntity user) {

this.test();

return user;

}

//@Transactional 服务上加了@Transactional后 这里可以不加

public void test(){

userDao.update(6);

if(userDao.update(6)){

TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

}

}

}

2、使用AspectJ 取代 Spring AOP 代理

上面的两个问题@Transactional 注解只应用到 public 方法和自调用问题，是由于使用 Spring AOP 代理造成的。为解决这两个问题，使用 AspectJ 取代 Spring AOP 代理。

需要将下面的 AspectJ 信息添加到 xml 配置信息中。

清单 6. AspectJ 的 xml 配置信息

class="org.springframework.jdbc.datasource.DataSourceTransactionManager">

class="org.springframework.transaction.aspectj.AnnotationTransactionAspect"

factory-method="aspectOf">

同时在 Maven 的 pom 文件中加入 spring-aspects 和 aspectjrt 的 dependency 以及 aspectj-maven-plugin。

清单 7. AspectJ 的 pom 配置信息

org.springframework

spring-aspects

4.3.2.RELEASE

org.aspectj

aspectjrt

1.8.9

org.codehaus.mojo

aspectj-maven-plugin

1.9

true

org.springframework

spring-aspects

compile

test-compile

5 详细说明

5.1 事务管理方式

在Spring中，事务有两种实现方式，分别是编程式事务管理和声明式事务管理两种方式。

编程式事务管理： 编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。

声明式事务管理： 建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。

声明式事务管理不需要入侵代码，通过@Transactional就可以进行事务操作，更快捷而且简单，推荐使用。

5.2 事务处理 @Transactional注解的使用

Spring团队的建议是你在具体的类(或类的方法)上使用 @Transactional 注解，而不要使用在类所要实现的任何接口上。你当然可以在接口上使用 @Transactional 注解，但是这将只能当你设置了基于接口的代理时它才生效。因为注解是不能继承的，这就意味着如果你正在使用基于类的代理时，那么事务的设置将不能被基于类的代理所识别，而且对象也将不会被事务代理所包装(将被确认为严重的)。因此，请接受Spring团队的建议并且在具体的类上使用 @Transactional 注解。

@Transactional 注解应该只被应用到 public 修饰的方法上。 如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不会报错， 但是这个被注解的方法将不会展示已配置的事务设置。

Spring的AOP即声明式事务管理默认是针对unchecked exception回滚。也就是默认对RuntimeException()异常或是其子类进行事务回滚。checked异常,即Exception可try{}捕获的不会回滚，因此对于我们自定义异常，通过rollbackFor进行设定。

如果我们需要捕获异常后，同时进行回滚，通过TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();进行手动回滚操作。

使用Object savePoint = TransactionAspectSupport.currentTransactionStatus().createSavepoint(); 设置回滚点，使用TransactionAspectSupport.currentTransactionStatus().rollbackToSavepoint(savePoint);回滚到savePoint。

5.3 事务提交方式

默认情况下，数据库处于自动提交模式。每一条语句处于一个单独的事务中，在这条语句执行完毕时，如果执行成功则隐式的提交事务，如果执行失败则隐式的回滚事务。

对于正常的事务管理，是一组相关的操作处于一个事务之中，因此必须关闭数据库的自动提交模式。不过，这个我们不用担心，spring会将底层连接的自动提交特性设置为false。也就是在使用spring进行事物管理的时候，spring会将是否自动提交设置为false，等价于JDBC中的 connection.setAutoCommit(false);，在执行完之后在进行提交，connection.commit(); 。

5.4 注解@Transactional常用配置

参 数 名 称功 能 描 述

readOnly

该属性用于设置当前事务是否为只读事务，设置为true表示只读，false则表示可读写，默认值为false。例如：@Transactional(readOnly=true)

rollbackFor

rollbackFor    该属性用于设置需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，则进行事务回滚。例如：指定单一异常类：@Transactional(rollbackFor=RuntimeException.class)指定多个异常类：@Transactional(rollbackFor={RuntimeException.class, Exception.class})

rollbackForClassName

该属性用于设置需要进行回滚的异常类名称数组，当方法中抛出指定异常名称数组中的异常时，则进行事务回滚。例如：指定单一异常类名称@Transactional(rollbackForClassName=”RuntimeException”)指定多个异常类名称：@Transactional(rollbackForClassName={“RuntimeException”,”Exception”})

noRollbackFor

该属性用于设置不需要进行回滚的异常类数组，当方法中抛出指定异常数组中的异常时，不进行事务回滚。例如：指定单一异常类：@Transactional(noRollbackFor=RuntimeException.class)指定多个异常类：@Transactional(noRollbackFor={RuntimeException.class, Exception.class})

noRollbackForClassName

该属性用于设置不需要进行回滚的异常类名称数组，当方法中抛出指定异常名称数组中的异常时，不进行事务回滚。例如：指定单一异常类名称：@Transactional(noRollbackForClassName=”RuntimeException”)指定多个异常类名称：@Transactional(noRollbackForClassName={“RuntimeException”,”Exception”})

propagation

该属性用于设置事务的传播行为。例如：@Transactional(propagation=Propagation.NOT_SUPPORTED,readOnly=true)

isolation

该属性用于设置底层数据库的事务隔离级别，事务隔离级别用于处理多事务并发的情况，通常使用数据库的默认隔离级别即可，基本不需要进行设置

timeout

该属性用于设置事务的超时秒数，默认值为-1表示永不超时

事物超时设置: @Transactional(timeout=30) //默认是30秒

5.5 Propagation的属性(事务的传播行为)

例如：@Transactional(propagation=Propagation.NOT_SUPPORTED,readOnly=true)

Propagation属性

含义

REQUIRED

默认值 在有transaction状态下执行；如当前没有transaction，则创建新的transaction；

SUPPORTS

如当前有transaction，则在transaction状态下执行；如果当前没有transaction，在无transaction状态下执行；

MANDATORY

必须在有transaction状态下执行，如果当前没有transaction，则抛出异常IllegalTransactionStateException；

REQUIRES_NEW

创建新的transaction并执行；如果当前已有transaction，则将当前transaction挂起；

NOT_SUPPORTED

在无transaction状态下执行；如果当前已有transaction，则将当前transaction挂起；

NEVER

在无transaction状态下执行；如果当前已有transaction，则抛出异常IllegalTransactionStateException。

5.6 事务5种隔离级别

例如：@Transactional(isolation = Isolation.READ_COMMITTED)

隔离级别含义

DEFAULT

这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别.

另外四个与JDBC的隔离级别相对应；

READ_UNCOMMITTED

最低的隔离级别。事实上我们不应该称其为隔离级别，因为在事务完成前，其他事务可以看到该事务所修改的数据。而在其他事务提交前，该事务也可以看到其他事务所做的修改。可能导致脏，幻，不可重复读

READ_COMMITTED

大多数数据库的默认级别。在事务完成前，其他事务无法看到该事务所修改的数据。遗憾的是，在该事务提交后，你就可以查看其他事务插入或更新的数据。这意味着在事务的不同点上，如果其他事务修改了数据，你就会看到不同的数据。可防止脏读，但幻读和不可重复读仍可以发生。

REPEATABLE_READ

比ISOLATION_READ_COMMITTED更严格，该隔离级别确保如果在事务中查询了某个数据集，你至少还能再次查询到相同的数据集，即使其他事务修改了所查询的数据。然而如果其他事务插入了新数据，你就可以查询到该新插入的数据。可防止脏读，不可重复读，但幻读仍可能发生。

SERIALIZABLE

完全服从ACID的隔离级别，确保不发生脏读、不可重复读和幻影读。这在所有隔离级别中也是最慢的，因为它通常是通过完全锁定当前事务所涉及的数据表来完成的。代价最大、可靠性最高的隔离级别，所有的事务都是按顺序一个接一个地执行。避免所有不安全读取。

5.7 事务回滚规则

指示spring事务管理器回滚一个事务的推荐方法是在当前事务的上下文内抛出异常。spring事务管理器会捕捉任何未处理的异常，然后依据规则决定是否回滚抛出异常的事务。

默认配置下，spring只有在抛出的异常为运行时unchecked异常时才回滚该事务，也就是抛出的异常为RuntimeException的子类(Errors也会导致事务回滚)，而抛出checked异常则不会导致事务回滚。

可以明确的配置在抛出那些异常时回滚事务，包括checked异常。也可以明确定义那些异常抛出时不回滚事务。

5.8 事物注意事项

要根据实际的需求来决定是否要使用事物，最好是在编码之前就考虑好，不然到以后就难以维护；

如果使用了事物，请务必进行事物测试，因为很多情况下以为事物是生效的，但是实际上可能未生效！

事物@Transactional的使用要放再类的公共(public)方法中，需要注意的是在 protected、private 方法上使用 @Transactional 注解，它也不会报错(IDEA会有提示)，但事务无效。

事物@Transactional是不会对该方法里面的子方法生效！也就是你在公共方法A声明的事物@Transactional，但是在A方法中有个子方法B和C，其中方法B进行了数据操作，但是该异常被B自己处理了，这样的话事物是不会生效的！反之B方法声明的事物@Transactional，但是公共方法A却未声明事物的话，也是不会生效的！如果想事物生效，需要将子方法的事务控制交给调用的方法，在子方法中使用rollbackFor注解指定需要回滚的异常或者将异常抛出交给调用的方法处理。一句话就是在使用事物的时候子方法最好将异常抛出！

事物@Transactional由spring控制的时候，它会在抛出异常的时候进行回滚。如果自己使用catch捕获了处理了，是不生效的，如果想生效可以进行手动回滚或者在catch里面将异常抛出，比如throw new RuntimeException();。

@Transactional可以放在Controller下面直接起作用，看到网上好多同学说要放到@Component下面或者@Service下面，经过试验，可以不用放在这两个下面也起作用。

@Transactional引入包问题，她有两个包：import javax.transaction.Transactional; 和 import org.springframework.transaction.annotation.Transactional; 这两个都可以用，对比了一下他们两个的方法和属性，发现后面的比前面的强大。建议后后面的。

PlatformTransactionManager 这个接口中定义了三个方法 getTransaction创建事务，commit 提交事务，rollback 回滚事务。她的实现类是 AbstractPlatformTransactionManager这个。

5.9 事务并发会产生什么问题

术语含义

脏读

A事务读取到了B事务还未提交的数据，如果B未提交的事务回滚了，那么A事务读取的数据就是无效的，这就是数据脏读

不可重复读

在同一个事务中，多次读取同一数据返回的结果不一致，这是由于读取事务在进行操作的过程中，如果出现更新事务，它必须等待更新事务执行成功提交完成后才能继续读取数据，这就导致读取事务在前后读取的数据不一致的状况出现

幻读

A事务读取了几行记录后，B事务插入了新数据，并且提交了插入操作，在后续操作中A事务就会多出几行原本不存在的数据，就像A事务出现幻觉，这就是幻读

1)第一类丢失更新：

在没有事务隔离的情况下，两个事务都同时更新一行数据，但是第二个事务却中途失败退出， 导致对数据的两个修改都失效了。

例如：

张三的工资为5000，事务A中获取工资为5000，事务B获取工资为5000，汇入100，并提交数据库，工资变为5100，

随后

事务A发生异常，回滚了，恢复张三的工资为5000，这样就导致事务B的更新丢失了。

2)脏读：

脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。

例如：

张三的工资为5000,事务A中把他的工资改为8000,但事务A尚未提交。

与此同时，

事务B正在读取张三的工资，读取到张三的工资为8000。

随后，

事务A发生异常，而回滚了事务。张三的工资又回滚为5000。

最后，

事务B读取到的张三工资为8000的数据即为脏数据，事务B做了一次脏读。

3)不可重复读：

是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。

例如：

在事务A中，读取到张三的工资为5000，操作没有完成，事务还没提交。

与此同时，

事务B把张三的工资改为8000，并提交了事务。

随后，

在事务A中，再次读取张三的工资，此时工资变为8000。在一个事务中前后两次读取的结果并不致，导致了不可重复读。

4)第二类丢失更新：

不可重复读的特例。

有两个并发事务同时读取同一行数据，然后其中一个对它进行修改提交，而另一个也进行了修改提交。这就会造成第一次写操作失效。

例如：

在事务A中，读取到张三的存款为5000，操作没有完成，事务还没提交。

与此同时，

事务B，存储1000，把张三的存款改为6000，并提交了事务。

随后，

在事务A中，存储500，把张三的存款改为5500，并提交了事务，这样事务A的更新覆盖了事务B的更新。

5)幻读：

是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。

例如：

目前工资为5000的员工有10人，事务A读取所有工资为5000的人数为10人。

此时，

事务B插入一条工资也为5000的记录。

这是，事务A再次读取工资为5000的员工，记录为11人。此时产生了幻读。

提醒：

不可重复读的重点是修改，同样的条件，你读取过的数据，再次读取出来发现值不一样了

幻读的重点在于新增或者删除，同样的条件，第 1 次和第 2 次读出来的记录数不一样

6 结语

由于本人才接触SprintBoot，文中如有没说清楚的地方，希望大家能在评论区指出，以帮助我将博文写得更好。

参考；