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

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

我们在使用Spring时候一般都知道事务在遇到异常的时候会回滚.岂不知Spring的事务默认仅仅有在发生执行时异常即:RunTimeException时才会发生事务,假设一个方法抛出Exception或者Checked异常Spring的事务并不会回滚. 以下我们来看看异常的分类.异常一般分为Checked异常和RunTime异常. CheckedException: Java觉得Checked异常都是能够被处理的异常,所以Java程序必须显式的处理Checked异常,假设程序没有处理checke

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

转载:spring多个AOP执行先后顺序(面试问题:怎么控制多个aop的执行循序) 众所周知,spring声明式事务是基于AOP实现的,那么,如果我们在同一个方法自定义多个AOP,我们如何指定他们的执行顺序呢?网上很多答案都是指定order,order越小越是最先执行,这种也不能算是错,但有些片面. 配置AOP执行顺序的三种方式 通过实现org.springframework.core.Ordered接口 @Component @Aspect @Slf4j public class Messag

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

文章目录 前言 正文 事务切面的调用过程 事务的传播性概念 实例分析 总结 前言 上一篇分析了事务注解的解析过程,本质上是将事务封装为切面加入到AOP的执行链中,因此会调用到MethodInceptor的实现类的invoke方法,而事务切面的Interceptor就是TransactionInterceptor,所以本篇直接从该类开始. 正文 事务切面的调用过程 public Object invoke(MethodInvocation invocation) throws Throwable

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

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

使用spring声明式事务,spring使用AOP来支持声明式事务,会根据事务属性,自动在方法调用之前决定是否开启一个事务,并在方法执行之后决定事务提交或回滚事务.

梦中惊醒 在Tomcat的线程池里,有这样一个线程,自打出生后,从来不去干活儿,有好多次走出线程池“这座大山”去看世界的机会,都被他拱手让给了弟兄们. 弟兄们给他取了个名字叫二师兄.没错,好吃懒做,饱了睡,醒了吃.这不,又迷迷糊糊睡着了,还打呼噜呢. “快起来,起来,干活去了”,有人在喊他.只见二师兄转转身,不耐烦道,“叫别人去,叫别人去”. “哪还有别人呢”,突然声音高了八度.二师兄觉得不对劲儿啊,转身一看,原来是大管家亲自来了,吓得他赶紧跳起来向外跑去. 远方来客 二师兄来到大门外,看到一众

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

1.数据并发问题 脏读 A事务读取B事务尚未提交的更新数据,并在此数据的基础上操作.如果B事务回滚,则A事务读取的数据就是错误的.即读取了脏数据或者错误数据. 不可重复组 A事务先后读取了B事务提交[更新]之前和提交更新之后的数据,两者数据不一致.A和B读取同一个数据. 幻象读 A事务先后读取B事务提交[新增]之前和提交新增之后的数据,两者数据不一致.A和B读取的数据范围不一致,A读取范围大于B的. 丢失更新 A事务提交或回滚时,将B事务的更新操作覆盖. 2.spring事务管理api Spri

1.@Transactional 只能被应用到public方法上, 对于其它非public的方法,如果标记了@Transactional也不会报错,但方法没有事务功能.@Transactional 的最有用的可选属性为:propagation(事务传播属性)和isolation(事务隔离级别) 2.默认情况下,一个有事务方法, 遇到RuntiomeException 时会回滚 . 遇到 受检查的异常 是不会回滚 的. 要想所有异常都回滚,要加上 @Transactional( rollbackF

上文见<spring事务管理器设计思想(一)> 对于第二个问题,涉及到事务的传播级别,定义如下: PROPAGATION_REQUIRED-- 如果当前没有事务,就新建一个事务.这是最常见的选择.  PROPAGATION_SUPPORTS-- 如果当前没有事务,就以非事务方式执行.  PROPAGATION_MANDATORY-- 如果当前没有事务,就抛出异常.  PROPAGATION_REQUIRES_NEW--新建事务,如果当前存在事务,把当前事务挂起.  PROPAGATION_NO

在最近做的一个项目里面,涉及到多数据源的操作,比较特殊的是,这多个数据库的表结构完全相同,由于我们使用的ibatis框架作为持久化层,为了防止每一个数据源都配置一套规则,所以重新实现了数据源,根据线程变量中指定的数据库连接名称来获取实际的数据源. 一个简单的实现如下: public class ProxyDataSource implements DataSource { /** 数据源池配置 */ private Map<String, DataSource> dataSourcePoolC

事务的几种传播特性1. PROPAGATION_REQUIRED: 如果存在一个事务,则支持当前事务.如果没有事务则开启2. PROPAGATION_SUPPORTS: 如果存在一个事务,支持当前事务.如果没有事务,则非事务的执行3. PROPAGATION_MANDATORY: 如果已经存在一个事务,支持当前事务.如果没有一个活动的事务,则抛出异常.4. PROPAGATION_REQUIRES_NEW: 总是开启一个新的事务.如果一个事务已经存在,则将这个存在的事务挂起.5. PROPAGA

Spring声明式事务让我们从复杂的事务处理中得到解脱.使得我们再也无需要去处理获得连接.关闭连接.事务提交和回滚等这些操作.再也无需要我们在与事务相关的方法中处理大量的try-catch-finally代码. 我们在使用Spring声明式事务时,有一个非常重要的概念就是事务属性.事务属性通常由事务的传播行为,事务的隔离级别,事务的超时值和事务只读标志组成.我们在进行事务划分时,需要进行事务定义,也就是配置事务的属性. Spring在TransactionDefinition接口中定义这些属性,

Spring抽象的DAO体系兼容多种数据访问技术,它们各有特色,各有千秋.像Hibernate是非常优秀的ORM实现方案,但对底层SQL的控制不太方便:而iBatis则通过模板化技术让你方便地控制SQL,但没有Hibernate那样高的开发效率:自由度最高的当然是直接使用Spring JDBC了,但它也是底层的,灵活的代价是代码的繁复.很难说哪种数据访问技术是最优秀的,只有在某种特定的场景下才能给出答案.所以在一个应用中,往往采用多个数据访问技术:一般是两种,一种采用ORM技术框架,而另一种采用

一.Propagation (事务的传播属性) Propagation : key属性确定代理应该给哪个方法增加事务行为.这样的属性最重要的部份是传播行为.有以下选项可供使用:PROPAGATION_REQUIRED--支持当前事务,如果当前没有事务,就新建一个事务.这是最常见的选择.PROPAGATION_SUPPORTS--支持当前事务,如果当前没有事务,就以非事务方式执行.PROPAGATION_MANDATORY--支持当前事务,如果当前没有事务,就抛出异常.PROPAGATION_RE