Spring的事务传播行为

  1. REQUIRED(默认)
  2. REQUIRES_NEW
  3. SUPPORTS(支持)
  4. NOT_SUPPORTED(不支持)
  5. NEVER
  6. MANDATORY(强制性的)
  7. NESTED(嵌套)

一、REQUIRED

(当前存在事务就用当前,没有就创建新的事务)

当前方法必须在Transaction中运行,支持当前已经存在的事务,如果还没有事务,就创建一个新事务。这是默认值,也即不进行该参数配置等于配置成REQUIRED。

Class A {
    @Transactional(propagation=propagation.REQUIRED)
    public void funA {
        B b = new B();
        b.funB();
    }
}
 
Class B {
    @Transactional(propagation=propagation.REQUIRED)
    public void funB { 
     // doSomeThing
    }
}

在这里插入图片描述

purchase代表两个声明了事务的方法,并且传播行为是系统的默认行为。同时checkout也是一个声明了事务的方法,在该方法中调用前述的两个方法。当checkout执行到第一个方法的时候,第一个方法继续使用checkout的事务进行执行,第二个方法一样,所以整个方法只有一个事务。

对于这样的配置,如果funB过程中发生异常需要回滚,那么funA中所进行的所有数据库操作也将同时被回滚,因为这两个方法使用了同一个事务。


二、REQUIRES_NEW

(无论如何创建一个新的事务)

当前方法必须运行在它自己的事务中。一个新的事务将被启动,如果存在当前事务,在该方法执行期间,当前事务会被挂起(如果一个事务已经存在,则先将这个存在的事务挂起)。

在这里插入图片描述


如果一个事务发生了错误,那么回滚。所以REQUIRED属性中,如果第二个方法发生错误,第一个方法也会回滚,然而REQUIRES_NEW属性中,第二个方法发生错误,因为第一个是单独的事务,所以不会受到影响。


那么,如果两个混合使用呢?
(为简单起见,REQUIRED在下述表达称为系统默认,REQUIRES_NEW称为new)


现在测试第一种方法的属性为系统默认,第二种方法为new,第二种方法出现错误。此时结果是方法1也回滚。但是按照前面的理解,方法2是单独的事务,应该只造成自己回滚,为什么第一种方法也会回滚?

第一种方法发生错误后,产生错误造成本身回滚,但是他的异常因为没有捕获,所以传到了主方法的事务中,主方法的事务出现错误,所以回滚,第一个方法在主方法的事务中,所以第一个方法的SQL语句会回滚!

如果第一种方法为new,第二种方法为系统默认,那么第二种发生错误后,主方法的事务回滚,然后第一种方法是自己的事务,所以不受影响,不会回滚,第一个方法的SQL语句就会执行。


三、SUPPORTS

(支持事务)

当前方法不需要在Transaction中运行,如果存在已经定义的Transaction,且该方法在定义的事务范围内被调用,则该方法也可以在事务中正常执行。如果方法在事务范围外被调用,该方法就在没有事务的环境下执行。


四、NOT_SUPPORTED

(不支持事务)

声明方法不需要事务。如果方法没有关联到一个事务,容器不会为他开启事务,如果方法在一个事务中被调用,该事务会被挂起,调用结束后,原先的事务会恢复执行。


五、NEVER

该方法绝对不能在事务范围内执行。如果在就抛例外。只有该方法没有关联到任何事务,才正常执行。


六、MANDATORY

(强制性的)

支持当前已经存在的事务,如果还没有事务,就抛出一个异常。该方法只能在一个已经存在的事务中执行,业务方法不能发起自己的事务。如果在没有事务的环境下被调用,容器抛出异常。

Class A {
    @Transactional(propagation=propagation.MANDATORY)
    public void funA {
        B b = new B();
        b.funB();
    }
}
 
Class B {
    @Transactional(propagation=propagation.REQUIRED)
    public void funB { 
     // doSomeThing
    }
}

七、NESTED

(嵌套)

外层事务失败时,会回滚内层事务所做的动作。而内层事务操作失败并不会引起外层事务的回滚。如果当前已经存在一个事务,那么该方法将会在嵌套事务中运行。嵌套的事务可以独立于当前事务进行单独地提交或回滚。如果当前事务不存在,那么其行为与REQUIRED一样。嵌套事务一个非常重要的概念就是内层事务依赖于外层事务。

@Transactional(rollbackFor=Exception.class)
public String a() {
	this.bSerivce..b();
	dosomething...
}

@Transactional(propagation = Propagation.NESTED)
public void  b(){
	dosomething...
}
课程简介: 课程总计41课时,从什么是事务讲起,直到分布式事务解决方案,很的0基础基础与提升系列课程。对于难以理解的知识点,全部用画图+实战的方式讲解。 第一部分:彻底明白事务的四个特性:原子性、一致性、隔离性、持久性,用场景和事例来讲解。 第二部分:实战讲数据库事务的6中并发异常:回滚丢失、覆盖丢失、脏读、幻读、不可重复读、MVCC精讲。 第三部分:彻底搞清楚4种事务隔离级别:READ_UNCOMMITTED 读未提交隔离级别、READ_COMMITTED 读已提交隔离级别、REPEATABLE_READ 可重复度隔离级别、SERIALIZABLE 序列化隔离级别 第四部分:彻底搞清楚MySQL的各种锁:行锁、表锁、共享锁、排它锁、Next-Key锁、间隙锁、X锁、S锁、IS锁、IX锁、死锁、索引与锁、意向锁等。 第五部分:彻底搞清楚Spring事务的7种传播级别的原理和使用:PROPAGATION_REQUIRED、PROPAGATION_SUPPORTS、PROPAGATION_MANDATORY、PROPAGATION_REQUIRES_NEW、PROPAGATION_NOT_SUPPORTED、PROPAGATION_NEVER、PROPAGATION_NESTED分布式事务的理论基础:RPC定理、BASE理论、XA协议都是什么,原理是什么,有什么关联关系 第六部分:分布式事务的5种解决方案原理和优缺点:2PC两阶段提交法、3PC三阶段提交法、TCC事务补偿、异步确保策略、最大努力通知策略 第七部分:阿里巴巴分布式事务框架Seata:历经多年双十一,微服务分布式事务框架,用一个Nacos+Spring Cloud+Seta+MySql的微服务项目,实战讲解阿里的分布式事务技术,深入理解和学习Seata的AT模式、TCC模式、SAGA模式。 课程资料: 课程附带配套2个项目源码72页高清PDF课件一份阿里巴巴seata-1.1.0源码一份阿里巴巴seata-server安装包一份
Spring框架中,事务传播行为用于定义一个方法调用时如何参与到已存在的事务中,或者如何创建一个新的事务Spring框架提供了多种事务传播行为选项,可以通过@Transactional注解或者编程式事务管理来配置。 以下是一些常见的Spring事务传播行为: 1. REQUIRED(默认):如果当前存在事务,则加入该事务;如果没有事务,则创建一个新的事务。这是最常用的传播行为,适合大多数情况。 2. SUPPORTS:如果当前存在事务,则加入该事务;如果没有事务,则以非事务的方式执行。适用于不需要强制要求事务的场景。 3. MANDATORY:如果当前存在事务,则加入该事务;如果没有事务,则抛出异常。适用于必须在一个已存在的事务中执行的场景。 4. REQUIRES_NEW:创建一个新的事务,并挂起当前的事务(如果存在)。适用于需要独立的事务执行的场景。 5. NOT_SUPPORTED:以非事务的方式执行操作,挂起当前的事务(如果存在)。适用于不需要事务支持的场景。 6. NEVER:以非事务的方式执行操作,如果当前存在事务,则抛出异常。适用于必须在没有事务的环境下执行的场景。 7. NESTED:如果当前存在事务,则在嵌套事务中执行;如果没有事务,则创建一个新的事务。嵌套事务是独立于外部事务的内部事务,它可以独立地进行提交或回滚,但是如果外部事务回滚,嵌套事务也会回滚。 通过选择合适的事务传播行为,可以确保在不同的方法调用中有效地管理事务,保证事务的一致性和可靠性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值