1 //假设这是一个service类的片段
 2 
 3 try{ 
 4 //出现异常
 5 } catch (Exception e) {
 6 e.printStackTrace();
 7 //设置手动回滚
 8 TransactionAspectSupport.currentTransactionStatus()
 9 .setRollbackOnly();
10 }
11 //此时return语句能够执行
12 return xxx;




spring事务回滚后 会把异常继续抛出吗 spring事务部分回滚_java


如上:

  当我们需要在事务控制的service层类中使用try catch 去捕获异常后,就会使事务控制失效,因为该类的异常并没有抛出,就不是触发事务管理机制。怎样才能即使用try catch去捕获异常,而又让出现异常后spring回滚呢,这里就要用到

TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

完美解决问题。并且能够使该方法执行完。

spring事务,TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

在aop配置事务控制或注解式控制事务中,try...catch...会使事务失效,可在catch中抛出运行时异常throw new RuntimeException(e)或者手动回滚TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();使得事务生效,异常回滚。

——————————————————————————————

——————————————————————————————

——————————————————————————————

SPRINGBOOT2异常处理回滚事务详解(自动回滚/手动回滚/部分回滚)

1 问题背景

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

2 @TRANSACTIONAL 事务实现机制

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

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



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 开启事务以及手动提交事务,可以在服务类上加上两个注解

@AutowiredDataSourceTransactionManager dataSourceTransactionManager;@AutowiredTransactionDefinition 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 详细说明

5.1 事务管理方式

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

  • 编程式事务管理: 编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理,spring推荐使用TransactionTemplate。
  • 声明式事务管理: 建立在AOP之上的。其本质是对方法前后进行拦截,然后在目标方法开始之前创建或者加入一个事务,在执行完目标方法之后根据执行情况提交或者回滚事务。
  • 声明式事务管理不需要入侵代码,通过@Transactional就可以进行事务操作,更快捷而且简单,推荐使用。

5.2 事务提交方式

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

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

5.3 事务隔离级别

隔离级别是指若干个并发的事务之间的隔离程度。TransactionDefinition 接口中定义了五个表示隔离级别的常量:

  • TransactionDefinition.ISOLATION_DEFAULT:这是默认值,表示使用底层数据库的默认隔离级别。对大部分数据库而言,通常这值就是TransactionDefinition.ISOLATION_READ_COMMITTED。
  • TransactionDefinition.ISOLATION_READ_UNCOMMITTED:该隔离级别表示一个事务可以读取另一个事务修改但还没有提交的数据。该级别不能防止脏读,不可重复读和幻读,因此很少使用该隔离级别。比如PostgreSQL实际上并没有此级别。
  • TransactionDefinition.ISOLATION_READ_COMMITTED:该隔离级别表示一个事务只能读取另一个事务已经提交的数据。该级别可以防止脏读,这也是大多数情况下的推荐值。
  • TransactionDefinition.ISOLATION_REPEATABLE_READ:该隔离级别表示一个事务在整个过程中可以多次重复执行某个查询,并且每次返回的记录都相同。该级别可以防止脏读和不可重复读。
  • TransactionDefinition.ISOLATION_SERIALIZABLE:所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。

5.4 事务传播行为

所谓事务的传播行为是指,如果在开始当前事务之前,一个事务上下文已经存在,此时有若干选项可以指定一个事务性方法的执行行为。在TransactionDefinition定义中包括了如下几个表示传播行为的常量:

  • TransactionDefinition.PROPAGATION_REQUIRED:如果当前存在事务,则加入该事务;如果当前没有事务,则创建一个新的事务。这是默认值。
  • TransactionDefinition.PROPAGATION_REQUIRES_NEW:创建一个新的事务,如果当前存在事务,则把当前事务挂起。
  • TransactionDefinition.PROPAGATION_SUPPORTS:如果当前存在事务,则加入该事务;如果当前没有事务,则以非事务的方式继续运行。
  • TransactionDefinition.PROPAGATION_NOT_SUPPORTED:以非事务方式运行,如果当前存在事务,则把当前事务挂起。
  • TransactionDefinition.PROPAGATION_NEVER:以非事务方式运行,如果当前存在事务,则抛出异常。
  • TransactionDefinition.PROPAGATION_MANDATORY:如果当前存在事务,则加入该事务;如果当前没有事务,则抛出异常。
  • TransactionDefinition.PROPAGATION_NESTED:如果当前存在事务,则创建一个事务作为当前事务的嵌套事务来运行;如果当前没有事务,则该取值等价于TransactionDefinition.PROPAGATION_REQUIRED。

5.5 事务回滚规则

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

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

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

5.6 事务常用配置

  • readOnly:该属性用于设置当前事务是否为只读事务,设置为true表示只读,false则表示可读写,默认值为false。例如:@Transactional(readOnly=true);
  • 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表示永不超时。

5.7 事物注意事项

  1. 要根据实际的需求来决定是否要使用事物,最好是在编码之前就考虑好,不然到以后就难以维护;
  2. 如果使用了事物,请务必进行事物测试,因为很多情况下以为事物是生效的,但是实际上可能未生效!
  3. 事物@Transactional的使用要放再类的公共(public)方法中,需要注意的是在 protected、private 方法上使用 @Transactional 注解,它也不会报错(IDEA会有提示),但事务无效。
  4. 事物@Transactional是不会对该方法里面的子方法生效!也就是你在公共方法A声明的事物@Transactional,但是在A方法中有个子方法B和C,其中方法B进行了数据操作,但是该异常被B自己处理了,这样的话事物是不会生效的!反之B方法声明的事物@Transactional,但是公共方法A却未声明事物的话,也是不会生效的!如果想事物生效,需要将子方法的事务控制交给调用的方法,在子方法中使用rollbackFor注解指定需要回滚的异常或者将异常抛出交给调用的方法处理。一句话就是在使用事物的时候子方法最好将异常抛出!
  5. 事物@Transactional由spring控制的时候,它会在抛出异常的时候进行回滚。如果自己使用catch捕获了处理了,是不生效的,如果想生效可以进行手动回滚或者在catch里面将异常抛出,比如throw new RuntimeException();。
  6. @Transactional可以放在Controller下面直接起作用,看到网上好多同学说要放到@Component下面或者@Service下面,经过试验,可以不用放在这两个下面也起作用。
  7. @Transactional引入包问题,她有两个包:import javax.transaction.Transactional; 和 import org.springframework.transaction.annotation.Transactional; 这两个都可以用,对比了一下他们两个的方法和属性,发现后面的比前面的强大。建议后后面的。
  8. PlatformTransactionManager 这个接口中定义了三个方法 getTransaction创建事务,commit 提交事务,rollback 回滚事务。她的实现类是 AbstractPlatformTransactionManager这个。