在使用spring事务时,我们通常会把事务内的所有操作当成是一个原子操作.也就是当整个事务内的所有代码都执行完成后, 才会将所有的数据落实到数据库中.这样做有时也会给我们造成麻烦.比如以下场景: 根据图中描述的逻辑,如果我们把前两步封装到一个事务方法中,会造成当第三方服务回调我们服务时,我们根据id去查询记录时,发现记录不存在. 这说明,我们第一步执行的方法并没有生效.原因就是因为第1步和第2步同时存在于一个事务中,所以当执行第二步时, 数据库并没有生效,而此时, 第三方服务如果处理比较快的时候

本文内容 如何在spring事务提交之后进行一些操作,这些操作必须得在该事务成功提交后才执行,回滚则不执行. 要点 如何在spring事务提交之后操作 如何在spring事务回滚之后操作 实现方案 使用TransactionSynchronizationManager在事务提交之后操作 // send after tx commit but is async TransactionSynchronizationManager.registerSynchronization(new Transac

一.问题复现 1.场景 2个service方法, 方法A中调用方法B. 方法A 是核心业务方法,涉及多张表数据变更,为了保持数据一致,用spring事务注解:@Transactional(rollbackFor = Exception.class) 方法B 比较耗时,为了不影响核心业务,方法B 用@Async注解,单独开启一个线程去异步执行.(方法B在另外一个类里边,不能和A在同一个类). 2.出错原因 方法B是异步方法,导致方法A事务还没提交时(不一定出错,具体就看哪个线程执行的快了)方法B就

前言 本专题大纲: 本文为本专题倒数第二篇文章. 在上篇文章中我们一起学习了Spring中的事务抽象机制以及动手模拟了一下Spring中的事务管理机制,那么本文我们就通过源码来分析一下Spring中的事务管理到底是如何实现的,本文将选用Spring5.2.x版本. 从@EnableTransactionManagement开始 Spring事务管理的入口就是@EnableTransactionManagement注解,所以我们直接从这个注解入手,其源码如下: public @interface

该系列文章是本人在学习 Spring 的过程中总结下来的,里面涉及到相关源码,可能对读者不太友好,请结合我的源码注释 Spring 源码分析 GitHub 地址 进行阅读. Spring 版本:5.1.14.RELEASE 在开始阅读 Spring AOP 源码之前,需要对 Spring IoC 有一定的了解,可查看我的 <死磕Spring之IoC篇 - 文章导读> 这一系列文章 了解 AOP 相关术语,可先查看 <Spring AOP 常见面试题) > 这篇文章 该系列其他文章请

在开发过程中,遇到一个bug,产生bug的原因是spring事务提交晚于消息队列的生产消息,导致消息队列消费消息时获取到的数据不正确.这篇文章介绍问题的产生和一步步的解决过程. 一.问题的产生: 场景还原:接口中的一个方法,首先修改订单状态,然后向消息队列中生产消息,消息队列的消费者获取到消息检测订单状态,发现订单状态未更改. 代码: @Service(orderApi) public class OrderApiImpl implements OrderApi { @Resource MqSe

http://kingj.iteye.com/blog/1680350   spring事务传播机制实例讲解 博客分类:   spring java历险     天温习spring的事务处理机制,总结如下   对于SQL事务的概念以及ACID性质,可以参见我的另一篇博文 http://kingj.iteye.com/admin/blogs/1675011 spring的管理的事务可以分为如下2类: 逻辑事务   在spring中定义的事务通常指逻辑事务,提供比物理事务更抽象,方便的事务配置管理,

先说一下启动过程中的几个点: 加载配置文件: AbstractAutowireCapableBeanFactory.doCreateBean --> initializeBean --> applyBeanPostProcessorsAfterInitialization --> beanProcessor.postProcessAfterInitialization --> AbstractAutoProxyCreator.postProcessAfterInitializati

原创说明:本文为本人原创作品,绝非他处转载,转账请注明出处 1.事务的定义:事务是指多个操作单元组成的合集,多个单元操作是整体不可分割的,要么都操作不成功,要么都成功.其必须遵循四个原则(ACID). 原子性(Atomicity):即事务是不可分割的最小工作单元,事务内的操作要么全做,要么全不做: 一致性(Consistency):在事务执行前数据库的数据处于正确的状态,而事务执行完成后数据库的数据还是应该处于正确的状态,即数据完整性约束没有被破坏:如银行转帐,A转帐给B,必须保证A的钱一定转给

本文是对慕课网上"搞定SSM开发"路径的系列课程的总结,详细的项目文档和课程总结放在github上了.点击查看 本文对应慕课网上课程Spring事务管理,详情可查看:点我 1: 概念简析 事务:逻辑的一组操作,要么一起成功,要么一起失败. 事务的特性: 原子性:不可分割,要么都发生,要么都不发生 一致性:数据完整性保持一致 隔离性:不同的事务操作不能相互影响 (隔离级别) 持久性:事务提交后,对数据的改变是永久的 PlatformTransactionManager: 事务管理器类,不

转载请标识 https://me.csdn.net/wanghaitao4j https://blog.csdn.net/wanghaitao4j/article/details/83625260 本博客分为两点, 一个是spring事务实现原理源码解读(个人能力,初步解读), 二是spring事务的传播属性 简单案例,保存订单,修改商品数量 就是这两个方法,第一个方法中引用了第二个方法,都用@Transactional注解.debug调用shopping方法. spring事务实现的源码 在调

Spring虽然提供了灵活方便的事务管理功能,但这些功能都是基于底层数据库本身的事务处理机制工作的.要深入了解Spring的事务管理和配置,有必要先对数据库事务的基础知识进行学习. 何为数据库事务 “一荣俱荣,一损俱损”这句话很能体现事务的思想,很多复杂的事物要分步进行,但它们组成一个整体,要么整体生效,要么整体失效.这种思想反映到数据库上,就是多个SQL语句,要么所有执行成功,要么所有执行失败. 数据库事务有严格的定义,它必须同时满足 4 个特性:原子性(Atomic).一致性(Consist

不知道一些同学有没有这种疑问,为什么Mybtis中要配置dataSource,Spring的事务中也要配置dataSource?那么Mybatis和Spring事务中用的Connection是同一个吗?我们常用配置如下 <!--会话工厂 --> <bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"> <property name=&qu

前言 本专题大纲: 我重新整理了大纲,思考了很久,决定单独将MySQL的事务实现原理跟Spring中的事务示例分为两篇文章,因为二者毕竟没有什么实际关系,实际上如果你对MySQL的事务原理不感兴趣也可以直接跳过本文,等待接下来两篇应用及源码分析,不过我觉得知识的学习应该慢慢行成一个体系,为了建立一个完善的体系应该要对数据库本身事务的实现有一定认知才行. 本文为Spring事务专题第三篇,在前两篇文章中我们已经对Spring中的数据访问有了一定的了解,那么从本文开始我们正式接触事务,在分析Spri

Spring 事务 上文 使用SpringJDBC 1.JDBC事务控制 ​ 不管你现在使用的是那一种ORM开发框架,只要你的核心是JDBC,那么所有的事务处理都是围绕着JDBC开展的,而JDBC之中的事务控制是由Connection接口提供的方法: 1.关闭自动事务提交:connection.setAutoCommit(false); 2.事务手工提交: connection.commit(); 3.事务回滚: connection.rollback(); 在程序的开发之中事务的使用是存在有前

mysql是一种关系型数据库,关系型数据库一个重要的特性就是支持事务,这是区别于no-sql产品的一个核心特性.当然了,no-sql产品支持键值查询,不能支持sql语句,这也是一个区别.今天主要讨论下事务的提交流程,由于mysql插件式存储架构,导致开启binlog后,事务提交实质是二阶段提交,通过两阶段提交,来保证存储引擎和二进制日志的一致.本文仅讨论binlog未打卡状态下的提交流程,后续会讨论打开binlog选项后的提交逻辑.源码调试环境如下: 测试环境: OS:windows DB:my

MySQL作为一种关系型数据库,已被广泛应用到互联网中的诸多项目中.今天我们来讨论下事务的提交过程. MySQL体系结构 由于mysql插件式存储架构,导致开启binlog后,事务提交实质是二阶段提交,通过两阶段提交,来保证存储引擎和二进制日志的一致. 本文仅讨论binlog未打卡状态下的提交流程,后续会讨论打开binlog选项后的提交逻辑. 测试环境 OS:WIN7 ENGINE: bin-log:off DB: 测试条件 set autocommit=0; -- --------------

一.MySQL事务提交过程(一) MySQL作为一种关系型数据库,已被广泛应用到互联网中的诸多项目中.今天我们来讨论下事务的提交过程. 由于mysql插件式存储架构,导致开启binlog后,事务提交实质是二阶段提交,通过两阶段提交,来保证存储引擎和二进制日志的一致. 此目录节点只讨论binlog未打卡状态下的提交流程,后续会讨论打开binlog选项后的提交逻辑. 测试环境 OS:WIN7 ENGINE: bin-log:off DB: 测试条件 ; -- --------------------

使用EF开发应用程序的一个难点就在于对其DbContext的生命周期管理,你的管理策略是否能很好的支持上层服务 使用独立事务,使用嵌套事务,并行执行,异步执行等需求? Mehdi El Gueddari对此做了深入研究和优秀的工作并且写了一篇优秀的文章,为了方便更多的童鞋学习,我已将其翻译为中文系列 : 在EntityFramework6中管理DbContext的正确方式 当然,在使用Mehdi El Gueddari为我们提供的DbContextScope组件时,任然会遇到一些比较棘手的问题,

数据并发的问题 一个数据库可能拥有多个访问客户端,这些客户端都可以并发方式访问数据库.数据库中的相同数据可能同时被多个事务访问,如果没有采取必要的隔离措施,就会导致各种并发问题,破坏数据的完整性.这些问题可以归结为5类,包括3类数据读问题(脏读.不可重复读和幻象读)以及2类数据更新问题(第一类丢失更新和第二类丢失更新).下面,我们分别通过实例讲解引发问题的场景. 脏读(dirty read) A事务读取B事务尚未提交的更改数据,并在这个数据的基础上操作.如果恰巧B事务回滚,那么A事务读到的数据根