Spring 事务的传播机制

本文详细解析了Spring中定义的7种事务传播行为,并重点对比了PROPAGATION_REQUIRES_NEW和PROPAGATION_NESTED的区别,阐述了这两种传播行为在实际应用场景中的不同表现。

Spring 在 TransactionDefinition 接口中规定了 7 种类型的事务传播行为:


PROPAGATION_REQUIRED – 支持当前事务,如果当前没有事务,就新建一个事务。这是最常见的选择。

PROPAGATION_SUPPORTS – 支持当前事务,如果当前没有事务,就以非事务方式执行。

PROPAGATION_MANDATORY – 支持当前事务,如果当前没有事务,就抛出异常。


PROPAGATION_REQUIRES_NEW – 新建事务,如果当前存在事务,把当前事务挂起。

PROPAGATION_NOT_SUPPORTED – 以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。

PROPAGATION_NEVER – 以非事务方式执行,如果当前存在事务,则抛出异常。


PROPAGATION_NESTED – 如果当前存在事务,则在嵌套事务内执行。


这里主要解释一下 REQUIRES_NEW 和 NESTED 的区别:

PROPAGATION_REQUIRES_NEW 启动一个新的, 不依赖于环境的 “内部” 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行.

PROPAGATION_NESTED 开始一个 “嵌套的” 事务, 它是已经存在事务的一个真正的子事务. 潜套事务开始执行时, 它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套事务是外部事务的一部分, 只有外部事务结束后它才会被提交.

ServiceA {        
    void methodA() {          //methodA 为外部方法
        ServiceB.methodB();   //methodB 为内部方法
    }  

}  

ServiceB {   
    void methodB() {  
    }      
}     

如果ServiceA#methodA的事务属性为REQUIRED, ServiceB#methodB 的事务属性为 REQUIRES_NEW, 那么两者不会发生任何关系, ServiceA#methodA 和 ServiceB#methodB 不会因为对方的执行情况而影响事务的结果, 因为它们根本就是两个事务, 在 ServiceB#methodB 执行时 ServiceA#methodA 的事务已经挂起了

如果ServiceA#methodA的事务属性为REQUIRED, ServiceB#methodB 的事务属性为 NESTED,那么ServiceB#methodB 如果 rollback, 那么内部事务(即 ServiceB#methodB) 将回滚到它执行前的 SavePoint, 而外部事务(即 ServiceA#methodA) 可以有以下两种处理方式:

  1. 改写 ServiceA 如下
ServiceA {  

    /** 
     * 事务属性配置为 PROPAGATION_REQUIRED 
     */  
    void methodA() {  
        try {  
            ServiceB.methodB();  
        } catch (SomeException) {  
            // 执行其他业务, 如 ServiceC.methodC();  
        }  
    }  

}  

这种方式也是潜套事务最有价值的地方, 它起到了分支执行的效果, 如果 ServiceB.methodB 失败, 那么执行 ServiceC.methodC(), 而 ServiceB.methodB 已经回滚到它执行之前的 SavePoint, 所以不会产生脏数据(相当于此方法从未执行过), 这种特性可以用在某些特殊的业务中, 而 PROPAGATION_REQUIRED 和 PROPAGATION_REQUIRES_NEW 都没有办法做到这一点

2.代码不做任何修改, 那么如果内部事务(即 ServiceB#methodB) rollback, 那么首先 ServiceB.methodB 回滚到它执行之前的 SavePoint(在任何情况下都会如此), 外部事务(即 ServiceA#methodA) 将根据具体的配置决定自己是 commit 还是 rollback

### Spring事务传播机制详解 在Spring框架中,事务传播机制用于定义多个事务方法相互调用时的事务边界管理方式。这种机制通过`@Transactional(propagation = Propagation.XXX)`注解进行配置,并依赖于数据库的“事务管理器”(如`DataSourceTransactionManager`)实现[^1]。 #### 事务传播机制的核心接口 Spring事务传播机制的基础是`PlatformTransactionManager`和`TransactionDefinition`两个核心接口: - `PlatformTransactionManager`:负责事务的获取、提交和回滚操作。 ```java public interface PlatformTransactionManager { TransactionStatus getTransaction(TransactionDefinition definition); void commit(TransactionStatus status); void rollback(TransactionStatus status); } ``` - `TransactionDefinition`:定义了事务的基本属性,包括传播行为、隔离级别、超时时间以及是否只读等。 ```java public interface TransactionDefinition { int getPropagationBehavior(); int getIsolationLevel(); int getTimeout(); boolean isReadOnly(); } ``` 这些接口共同构成了Spring事务管理的底层支持体系[^2]。 #### 七种事务传播行为及其特性 Spring提供了七种不同的事务传播行为,每种行为适用于特定的业务场景: 1. **PROPAGATION_REQUIRED** 支持当前事务,如果没有事务则创建一个新的事务。这是默认的传播行为,适用于大多数业务场景。 2. **PROPAGATION_SUPPORTS** 支持当前事务,如果没有事务则以非事务方式执行。适用于对事务要求不高的查询操作。 3. **PROPAGATION_MANDATORY** 必须存在当前事务,否则抛出异常。适用于强制要求事务上下文的操作。 4. **PROPAGATION_REQUIRES_NEW** 创建一个新的事务并挂起当前事务。适用于需要独立事务的操作,避免与外部事务产生影响。 5. **PROPAGATION_NOT_SUPPORTED** 以非事务方式执行,如果当前存在事务则将其挂起。适用于不需要事务支持的操作,例如日志记录。 6. **PROPAGATION_NEVER** 以非事务方式进行,如果存在事务则抛出异常。适用于明确禁止事务的场景。 7. **PROPAGATION_NESTED** 如果当前存在事务,则在嵌套事务内执行;如果当前没有事务,则创建一个新事务。适用于需要部分回滚的复杂事务场景[^4]。 #### 事务传播机制的重要性 Spring事务传播机制为复杂业务场景提供了灵活的事务管理能力。通过合理配置传播行为,可以有效控制事务边界,避免数据不一致问题,同时提高系统的性能和稳定性[^3]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值