Spring事务异常回滚,try catch 捕获异常不回滚

本文探讨了在Spring框架中如何正确处理事务回滚的问题,特别是在一个方法内多个操作需要进行事务控制的情况下,通过不同方式实现异常处理及手动回滚。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 

 

 

今天敲项目的时候一个方法有两个事务,用了try catch之后一直出现一个报错一个不报错,不报错的却不回滚的现象,仔细检查解决问题

 

例:一个方法报异常,另一个方法不会回滚

try {       
        userDao.save(user);        
        userCapabilityQuotaDao.save(capabilityQuota);       
     } catch (Exception e) {              
    } 

例:一个方法报异常,另一个方法回滚

在catch语句中最后增加throw new RuntimeException()语句,以便让aop捕获异常再去回滚,并且在service上层(webservice客户端,view层action)要继续捕获这个异常并处理

try {        
        userDao.save(user);        
        userCapabilityQuotaDao.save(capabilityQuota);       
       } catch (Exception e) {       
        throw new RuntimeException();       
     }       

【现在的做法】在service层方法的catch语句中增加:TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();语句,手动回滚,这样上层就无需去处理异常了

try {        
        userDao.save(user);        
        userCapabilityQuotaDao.save(capabilityQuota);        
    } catch (Exception e) { 
        TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();       
    }  

 

其实像第一种try catch这种把整个包裹起来,这种业务方法也就等于脱离了spring事务的管理,因为没有任何异常会从业务方法中抛出,全被捕获并“吞掉”,导致spring异常抛出触发事务回滚策略失效。

 

如果在catch代码块中采用页面硬编码的方式使用spring api对事务做显式的回滚,这样写也是可以的。

 

### Spring 框架中 Try-Catch事务回滚的影响 在Spring框架内,`try-catch`结构确实能够影响到由`@Transactional`注解所定义的方法中的事务回滚行为。具体来说: - 默认情况下,只有未被捕捉的运行时异常(即继承自`RuntimeException`的异常)才会触发事务自动回滚[^2]。 - 如果在一个带有`@Transactional`注解的方法里使用了`try-catch`来捕获异常,则取决于如何处理这个异常以及是否有额外设置。 对于已检查异常,默认情况下它们会引起事务回滚;但是可以通过指定`rollbackFor`参数让某些类型的已检查异常也导致回滚操作。例如,在代码片段中可以看到如下配置: ```java @Transactional(rollbackFor = Exception.class) public void asyncJob() { success(); try { exception(); } catch (Exception e) { e.printStackTrace(); // 手工回滚异常 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); } } ``` 这段代码展示了如何利用`TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()`来进行手动回滚的操作[^3]。这使得即便是在`catch`块中处理过的异常也能使当前事务标记为只读模式从而实现回滚效果。 另外需要注意的是,如果希望整个方法执行失败后都能正常回滚论是否进入了`catch`分支,那么应该避免完全吞掉所有可能发生的错误而做任何响应或记录。比如下面的例子就可能导致预期之外的行为——尽管设置了全局性的回滚条件(`rollbackFor=Exception.class`),但由于存在空返回值且没有任何日志输出或其他形式的通知机制,可能会掩盖实际发生的问题[^5]: ```java @Override @Transactional(rollbackFor = Exception.class) public CommonResponse modifyTeaFormula(GemiTeaFormulaReq gemiTeaFormulaReq) { try { /* 省略部分业务逻辑 */ teaFormulaDao.deleteById(id); teaFormulaDetailDao.deleteById(id); } catch (Exception e) { logger.error("error:" + e.getMessage()); } return new CommonResponse(0); } ``` 为了确保事务按期望工作,建议遵循最佳实践:要么允许异常传播出去以便于框架可以识别并且回滚相应的更改;要么就在适当的位置加入显式的回滚指令,并考虑增加足够的调试信息帮助后续排查问题所在。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值