每日一博 | Spring 七种事务传播性介绍
作者:vivo 互联网服务器团队 - Zhou Shaobin
本文主要介绍了Spring事务传播性的相关知识。
Spring中定义了7种事务传播性:
-
PROPAGATION_REQUIRED
-
PROPAGATION_SUPPORTS
-
PROPAGATION_MANDATORY
-
PROPAGATION_REQUIRES_NEW
-
PROPAGATION_NOT_SUPPORTED
-
PROPAGATION_NEVER
-
PROPAGATION_NESTED
在Spring环境中,含有事务的方法嵌套调用,事务是如何传递的规则,以及每种规则是如何开展工作的。文章还提到每种事务传播性是如何使用的,方便读者依据实际的场景,使用不同的事务规则。
一、什么是Spring事务的传播性
Spring 事务传播性是指, 在Spring的环境中,当多个含有事务的方法嵌套调用时,每个事务方法都处于自己事务的上下文中,其提交或者回滚行为应该如何处理。
通俗讲,就是当一个事务方法调用另外一个事务方法时,事务如何跨上下文传播。
1)当事务方法A调用事务方法B时,事务方法B是合并到事务方法A中,还是开启新事务?
2)当事务方法B抛出异常时 ,在合并事务或者开启新的事务的场景中,事务的回滚是如何处理的 ?
以上事务的处理规则,都取决于事务传播级别的设置。
二、事务的传播性都有哪些行为
事务的传播行为,主要分为三种类型,分别是:支持当前事务、不支持当前事务、嵌套事务。
2.1 支持当前事务
REQUIRED:默认的事务传播级别,表示如果当前方法已在事务内,该方法就在当前事务中执行,否则,开启一个新的事务并在其上下文中执行。
SUPPORTED:当前方法在事务内,则在其上下文中执行该方法,否则,开启一个新的事务。
MANDATORY:必须在事务中执行,否则,将抛出异常。
2.2 不支持当前事务
REQUIRES_NEW:无论当前是否有事务上下文,都会开启一个事务 。如果已经有一个事务在执行 ,则正在执行的事务将被挂起 ,新开启的事务会被执行。
事务之间相互独立,互不干扰。
NOT_SUPPORTED:不支持事务,如果当前存在事务上下文,则挂起当前事务,然后以非事务的方式执行。
NEVER:不能在事务中执行,如果当前存在事务上下文,则抛出异常。
2.3 嵌套事务
NESTED:嵌套事务,如果当前已存在一个事务的上下文中,则在嵌套事务中执行,如果抛异常,则回滚嵌套事务,而不影响其他事务的操作。
三、每种事务的传播性如何工作
3.1 REQUIRED
默认的事务传播行为,保证多个嵌套的事务方法在同一个事务内执行,并且同时提交,或者出现异常时,同时回滚。
这个机制可以满足大多数业务场景。
例子 :
1)类TestAService的方法通过声明式事务的方式,加上了事务注解@Transactional ,并设置事务的传播性为REQUIRED。
2)调用者调用TestAService的A方法时,如果调用者没有开启事务,那么A方法会开启一个事务。
A方法的具体执行过程如下 :
a. 执行insert,但没有提交;
b.调用TestBServcie的B方法,由于B方法也声明了事务,并且传播性是REQUIRED,所以方法B的事务,合并到方法A开启的事务中。
c.方法B执行insert操作,此时也没有提交。
3)由于这两个方法的操作都在同一个事务中执行,当这两个方法所有操作执行成功之后,提交事务。
嵌套调用链路:
当方法B 执行时抛出了 Exception 异常后,事务是如何处理的 ?
1)方法B声明了事务,insert操作会回滚
2)由于方法A和方法B 同属一个事务,方法A也会执行回滚,由此说明该规则保证了事务的原子性。
嵌套调用,异常后的链路:
如果 方法B 抛出异常后,方法A 使用 try-catch 处理了方法B的异常(如下代码),并没有向外抛出,此时事务又如何处理的 ?
方法A也会回滚。
从事务的特性我们可知,事务具有原子性。方法A和方法B同属一个事务,当方法B抛出异常,触发回滚操作后,整个事务的操作都会回滚。
因此,Spring 在处理事务过程中,当事务的传播性设置为REQUIRED,在整个事务的调用链上,任何一个环节抛出的异常都会导致全局回滚。
3.2 REQUIRES_ NEW
每次都开启一 个新的事务。
例子:
上面例子中,方法B的传播性设置为 REQUIRES_NEW,方法A仍然是REQUIRED,当A调用B时,具体调用链路如下:
具体执行过程:
-
方法A被执行前,如果调用者没有开启事务,方法A开启一个事务1,然后执行insert ,此时没有提交;
-
方法B的事务传播性设置为REQUIRES_NEW,当被方法A调用时,此时方法A的事务1会被挂起,方法B开启自己的事务2,然后执行insert,此时并没有提交;
-
当方法B执行完毕后,提交事务2;
-
恢复事务1,最终提交。
当 方法B 执行时抛出了异常,会发生什么?
方法B的insert操作会被回滚掉,方法A不受影响。但这里有个前提,方法A需要try-catch方法B的异常,使其异常不会往上传递,从而导致方法A接收到异常,导致回滚。
3.3 SUPPORTED
当外层方法A存在事务,方法B加入到当前事务中,以事务的方式执行。
当外层方法A不存在事务,方法B不会创建新的事务,以非事务的方式执行。
例子1:
以上例子,方法A没有加事务注解,方法B的加了事务注解,并且传播为SUPPORTS。
具体执行过程:
-
方法A以非事务的方式执行insert操作。
-
方法B被调用,由于其外层事务A没有开启事务,方法B也是以非事务方法执行insert操作。
例子2:
以上例子,方法A和B都加上了事务注解,其中方法A的传播性为REQUIRED,方法B的传播性为SUPPORTS。
具体执行过程:
-
如果方法A的调用方没有开启事务,则方法A开启事务,并执行insert操作,但没有提交;
-
方法B被调用,由于其外层方法A开启了事务,因此方法B加入到方法A开启的事务中,并执行insert,但没有提交;
-
当事务中的所有操作执行成功后,事务提交。
3.4 NOT_SUPPORTED
不支持事务。
如果外层方法存在事务,则挂起外层事务,以非事务方式执行,执行完毕后,恢复外层事务。
例子:
以上例子:方法A和B都加上了事务注解,方法A的传播性为REQUIRED,方法B为NOT_SUPPORTED。
具体执行过程:
-
如A的调用方没有开启事务,方法A开启事务,并执行insert,但没有提交。
-
方法A调用方法B时,方法B的传播性为NOT_SUPPORTED,不支持事务,然后挂起外层方法A的事务,方法B以非事务的方式执行insert。
-
方法B执行完毕后,恢复方法A的事务,最终提交事务。
调用链路过程:
3.5 NEVER
不支持事务
当外层方法A开启了事务,方法B抛出异常
例子:
以上代码,两个方法都打上了事务注解,方法A的传播性是REQUIRED,方法B的传播性是NEVER。
具体执行过程:
-
方法A开启事务,执行insert,没有提交。
-
含有事务的方法A调用方法B,方法B的传播性是NEVER,表示不支持事务,因此方法B抛出异常。
-
方法A的事务执行回滚。
3.6 MANDATORY
必须在事务中执行。
如果外层方法A没有开启事务,方法B抛出异常。
如果外层方法A开启了事务,方法B加入事务,方法A&B在同一事务中执行。
例子:
以上例子,方法A没有加事务注解,方法B 的传播性为 MANDATORY。
具体执行过程:
-
方法A的调用方如果本身没有开启事务,方法A执行前不会开启事务。
-
当非事务方法A调用方法B时,由于方法B的传播性为MANDATORY,必须在事务中执行,条件不满足,抛出异常。
3.7 NESTED
嵌套事务
-
如果外层方法A不存在事务,内层方法B的规则与REQUIRED 一致。
-
如果外层方法A存在事务,内层方法B做为外层方法A事务的子事务执行,两个方法是一起提交,但子事务是独立回滚。
内层方法B抛出异常,则会回滚方法B的所有操作,但不影响外层事务方法A。(方法A需要try-catch子事务,避免异常传递到父层事务)
外层方法A回滚,则内层方法B也会回滚。
-
该传播性的特点是可以保存状态点,当回滚时,只会回滚到某一个状态点,保证了子事务之间的独立性,避免嵌套事务的全局回滚。
例子:
以上例子,方法A的传播性为REQUIRED,方法B为NESTED。
具体执行过程:
-
方法A执行时,如调用方没有开启事务,则开启一个事务。
-
方法B被外层方法A调用时,因为方法B的传播性为NESTED,方法B在此处建立savepoint,标记insert行为。
-
当方法B抛出异常,其insert操作会回滚,但只会回滚到savepoint,(前提是方法A要try-catch方法B,使方法B的异常不会往外传递)。
-
方法B回滚后,方法A的事务提交。
调用链路:
四、总结
本文解释了Spring框架中的事务传播性,即多个业务方法之间调用时事务如何处理的规则。Spring提供了七种传播级别,如
PROPAGATION_REQUIRED、
PROPAGATION_REQUIRES_NEW等。
每种级别都有适用场景和限制,本文提供了一些示例,介绍了声明式事务如何使用,每种事务的规则,产生哪种行为,当方法抛出异常时,事务的提交和回滚是如何被处理的。正确处理事务对于任何企业级应用程序都是必要的,了解Spring事务传播性是构建高效、可靠和可扩展应用程序的关键。
END
猜你喜欢
本文分享自微信公众号 - vivo互联网技术(vivoVMIC)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
贝佐斯参投 ,AI 搜索引擎 Perplexity 融资 7360 万美元
生成式 AI 搜索引擎初创公司 Perplexity AI表示,已成功筹集了 7360 万美元的 B 轮资金,这是近年来互联网搜索初创公司筹集的最大一笔资金。 该公司迄今为止共筹集了 1 亿美元的资金,估值已达到 5.2 亿美元。 B 轮融资由 Institutional Venture Partners LLC 领投,此前 A 轮和种子轮的现有投资者也参与其中:包括 NEA、Twitter 前副总裁 Elad Gil 和 Databricks Ventures。其他参投的还有 AI 芯片制造商巨头 Nvidia Corp.、Bessemer Venture Partners、Facility Funds、Kindred Ventures、Shopify 首席执行官 Tobi Lutke 以及 Amazon.com Inc. 创始人 Jeff Bezos(通过 Bezos Expeditions Fund)等新投资者。 Perplexity 搜索工具的操作方式与传统搜索引擎不同。它不需要人们输入提供结果列表的关键字,而是允许用户提出问题,搜索引擎以对话方式做出响应。通过这种方式,它可以...
- 下一篇
DreamTalk —— 音频驱动型表情包生成框架
DreamTalk 是一种基于 diffusion 的音频驱动型表情包生成框架,可以生成高质量的表情包视频,涵盖多种说话风格。DreamTalk 在处理各种输入(包括歌曲、多语言语音、嘈杂音频和域外肖像)时表现出强劲的性能。 具体来说,DreamTalk 由三个关键组件组成:去噪网络、风格感知唇部专家和风格预测器。基于扩散的去噪网络能够一致地合成不同表情的高质量音频驱动的面部运动。为了增强唇部动作的表现力和准确性,项目团队引入了风格感知型唇部专家,可以指导唇部同步,同时注意说话风格。为了消除对表情参考视频或文本的需要,利用额外的基于扩散的风格预测器直接从音频预测目标表情。通过这种方式,DreamTalk 可以利用强大的扩散模型有效地生成富有表现力的面孔,并减少对昂贵的风格参考的依赖。 实验结果表明,DreamTalk 能够生成具有多种说话风格的逼真说话面孔,并实现准确的嘴唇动作,超越了现有最先进的同类产品。
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS关闭SELinux安全模块
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- MySQL8.0.19开启GTID主从同步CentOS8
- Mario游戏-低调大师作品