1、背景
在我们的日常开发中,经常会存在在一个Service层中调用另外一个Service层的方法。比如
:我们有一个TaskService,里面有一个execTask方法,且这个方法存在事务,这个方法在执行完之后,需要调用LogService的insertLog方法记录一条日志,这个方法上也有事务,不管日志记录成功还是失败,都不能影响execTask方法的执行。因此我们很容易写出如下代码。
java
@Transactional
public void execTaskV1(){
log.info("开始执行任务");
try {
logService.insertLogV1();
} catch (Exception e) {
log.error("添加日志出现错误");
}
log.info("完成任务执行");
}
思考:
上方的代码,如果insertLogV1
跑出了异常,execTaskV1
方法的事务可以正常提交吗?
2、异常是如何实现出现的
1、了解Spring事务的传播属性
传播行为 | 描述 | 应用场景 | 行为特点 |
---|---|---|---|
Propagation.REQUIRED |
如果当前存在事务,则加入该事务;如果当前没有事务,则启动一个新的事务。 | 大多数场景,如多个方法需要在同一个事务中完成。 | - 如果当前事务存在,方法执行在当前事务上下文中。 - 如果当前事务不存在,创建新事务。 |
Propagation.SUPPORTS |
如果当前存在事务,则加入该事务;如果当前没有事务,则以非事务方式执行。 | 对事务支持没有强制要求的场景,如只读查询。 | - 如果当前事务存在,方法执行在当前事务上下文中。 - 如果当前事务不存在,以非事务方式执行。 |
Propagation.MANDATORY |
如果当前存在事务,则加入该事务;如果当前没有事务,则抛出异常。 | 必须在一个已存在的事务中执行的场景。 | - 必须在已有事务中执行,否则抛出 IllegalTransactionStateException 。 |
Propagation.REQUIRES_NEW |
每次调用该方法时都会启动一个新的事务。当前事务(如果有)会被挂起。 | 需要独立事务的场景,如日志记录或独立的业务操作。 | - 总是创建新事务。 - 当前事务(如果有)会被挂起,直到新事务完成。 |
Propagation.NOT_SUPPORTED |
总是以非事务方式执行,并且暂停当前事务(如果有)。 | 不需要事务的场景,如简单的查询操作。 | - 总是以非事务方式执行。 - 暂停当前事务(如果有)。 |
Propagation.NEVER |
总是以非事务方式执行,如果当前存在事务,则抛出异常。 | 严格禁止事务的场景,如某些非事务性操作。 | - 必须在非事务上下文中执行,否则抛出 TransactionException 。 |
Propagation.NESTED |
如果当前存在事务,则在嵌套事务内执行;如果当前没有事务,则启动一个新的事务。 | 需要嵌套事务的场景,如复杂的业务流程中需要独立的回滚点。 | - 如果当前事务存在,创建一个嵌套事务(依赖于数据库支持)。 - 如果当前事务不存在,创建新事务。 |
2、模拟异常出现
Transaction rolled back because it has been marked as rollback-only
这个异常在上述的案例中是如何实现的呢?
从上图中可知,出现了Transaction rolled back because it has been marked as rollback-only
这个异常,那么这个异常是如何出现的呢?
其实这个是和Spring事务的传播属性Propagation
有关。
默认情况下@Transaction
的传播属性是Propagation.REQUIRED
, 即如果当前存在事务,则加入该事务;如果当前没有事务,则启动一个新的事务。
在我们的例子中,事务的隔离级别都是Propagation.REQUIRED
,即是在同一个事务中,因此insertLogV1
方法抛出异常后,虽然上层捕获到了,但其实这个时候这个事务已经被标记成回滚
状态了,因此事务无法提交成功。
如何解决:
只需要修改insertLogV1
事务的传播属性为Propagation.REQUIRES_NEW
即可。
3、完整代码
完整代码-https://gitee.com/huan1993/spring-cloud-parent/tree/master/springboot/springboot-transaction-v1