spring事务管理

一、Spring事务传播属性（Propagation）： 1) REQUIRED（默认属性） 如果存在一个事务，则支持当前事务。如果没有事务则开启一个新的事务。 被设置成这个级别时，会为每一个被调用的方法创建一个逻辑事务域。如果前面的方法已经创建了事务，那么后面的方法支持当前的事务，如果当前没有事务会重新建立事务。 2) MANDATORY 支持当前事务，如果当前没有事务，就抛出异常。 3) NEVER 以非事务方式执行，如果当前存在事务，则抛出异常。 4) NOT_SUPPORTED 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。 5) REQUIRES_NEW 新建事务，如果当前存在事务，把当前事务挂起。 6) SUPPORTS 支持当前事务，如果当前没有事务，就以非事务方式执行。 7) NESTED 支持当前事务，新增Savepoint点，与当前事务同步提交或回滚。 嵌套事务一个非常重要的概念就是内层事务依赖于外层事务。外层事务失败时，会回滚内层事务所做的动作。而内层事务操作失败并不会引起外层事务的回滚。 PROPAGATION_NESTED 与PROPAGATION_REQUIRES_NEW的区别： 它们非常类似，都像一个嵌套事务，如果不存在一个活动的事务，都会开启一个新的事务。 使用PROPAGATION_REQUIRES_NEW时

整理了一些Java方面的架构、面试资料（微服务、集群、分布式、中间件等），有需要的小伙伴可以关注公众号【程序员内点事】，无套路自行领取 更多优选 一口气说出 9种 分布式ID生成方式，面试官有点懵了 面试总被问分库分表怎么办？你可以这样怼他 3万字总结，Mysql优化之精髓 技术部突然宣布：JAVA开发人员全部要会接口自动化测试框架 9种分布式ID生成之美团（Leaf）实战 絮絮叨叨 还记得刚入行开始写Java时，接触的第一个项目是国家电网的一个业务系统，这个系统据说投资了5亿人民币进行研发，鼎盛时期研发人员一度达到过500人。项目采用当时最流行的ssh（Struts+Spring+Hibernate）框架，典型的三层架构（controller - > service -> dao）简单又粗暴，所有人写的代码都放在一个大工程里，项目文件大小达到几百M，解决代码冲突是当时最大的工作量。 然而戏剧性的是，交测当天五人同时上线，项目崩 崩 崩溃了。。。 哎！你永远想象不到甲方愤怒的样子，项目组每个人的祖宗都被问候到了。 说了一些没用的，脑子里总想起这个事，不说不痛快，大家姑且就当笑话听吧，下边我们进入正题 引言 前两天有个学弟公众号留言，说让讲讲分布式事务，面试就挂在这个问题上。时下随着微服务架构体系的流行，面试的题目也都慢慢开始升级，不再是早些年单纯的问点SSH框架知识、数据结构了。

Spring框架的7个模块 组成 Spring框架的每个模块（或组件）都可以单独存在，或者与其他一个或多个模块联合实现。每个模块的功能如下： 核心容器 ： 核心容器提供 Spring框架的基本功能。核心容器的主要组件是 BeanFactory，它是工厂模式的实现。BeanFactory 使用 控制反转 （IOC）模式将 应用程序的配置和依赖性规范 与 实际的应用程序代码 分开。 那么我们该如何理解：BeanFactory和FactoryBean 1、 BeanFactory BeanFactory定义了IOC容器的最基本形式，并提供了 IOC 容器应遵守的的最基本的接口，也就是 Spring IOC 所遵守的最底层和最基本的编程规范。在Spring代码中，BeanFactory 只是个接口，并不是 IOC 容器的具体实现，但是 Spring 容器给出了很多种实现，如 DefaultListableBeanFactory 、 XmlBeanFactory 、 ApplicationContext 等，都是附加了某种功能的实现。 2、 FactoryBean 一般情况下，Spring通过反射机制利用<bean>的class属性指定实现类实例化Bean，在某些情况下，实例化Bean过程比较复杂，如果按照传统的方式，则需要在<bean>中提供大量的配置信息。配置方式的灵活性是受限的

出处： spring事务 1.背景 　　Spring提供了编程式事务和声明式事务，但由于编程性事务的侵入性，开发中普遍会使用Spring的声明式事务，下文中所说的Spring事务也都是指声明式事务。 　　Spring声明式事务底层是建立在AOP的基础上的，其本质就是对方法前后进行拦截，然后在目标方法之前创建或加入一个事务，在执行完目标方法之后根据执行执行情况提交或回滚事务。 　　声明式事务最大的优点就是不需要在业务逻辑代码中掺杂事务管理的代码，Spring事务提供两种事务管理方式：基于注解和基于XML配置，我们只需要简单的配置即可使用。 　　相比于编程式事务，由于声明式事务是基于AOP实现的，所以只能实现对方法的粗粒度的控制，而无法做到代码块级别的细粒度控制。 　　Spring事务包括5中参数，分别是：传播行为，隔离级别，是否只读，事务超时时间，回滚规则 　　本文分析下5种事务参数，然后对具体的传播行为给出Demo，以此给出其“细粒度”的事务实现。 2.Spring事务的5种参数 2.1 传播行为 　　传播行为定义了关于客户端和被调用方法的事务边界，Spring中定义了7中传播行为。 对嵌套事务的理解： 　　嵌套是子事务在父事务中执行，子事务是父事务的一部分，在进入子事务之前，父事务建立一个回滚点，叫save point，然后执行子事务，这个子事务也算是父事务的一部分

今天有个朋友问我一个事务不起作用的问题，如果对事务代理不了解的话，这个问题需要引起大家注意。 先看配置文件： <!-- 配置事务拦截器--> <bean id="transactionInterceptor" class="org.springframework.transaction.interceptor.TransactionInterceptor"> <!-- 事务拦截器bean需要依赖注入一个事务管理器 --> <property name="transactionManager" ref="myTransactionManager"/> <property name="transactionAttributes"> <!-- 下面定义事务传播属性--> <props> <!--del开头的方法都被事物管理--> <prop key="update*">PROPAGATION_REQUIRED</prop> <prop key="add*">PROPAGATION_REQUIRED</prop> <prop key="set*">PROPAGATION_REQUIRED</prop> <prop key="del*">PROPAGATION_REQUIRED</prop> <prop key="find*">PROPAGATION_REQUIRED,readOnly<

线上的系统中，使用的是Spring+Mybatis+Mysql搭建的框架，由于客户需要，最近一直在对性能提升部分进行考虑，主要是涉及Mysql的一些重要参数的配置学习，以及Spring事务管理机制的学习，因为通过观察服务器日志，发现在这两部分的时候耗时比较严重，特别是进行mysql事务提交的时候，项目源码中使用了Spring的声明式事务，即通过@Transactional注解来控制事务的开启与提交，这两天看了一些关于Spring Transaction事务的一些文章，也debug了源码，总算有点心得和疑问，这里简单的整理一下。 在Spring的配置文件中，我们使用了"org.springframework.jdbc.datasource.DataSourceTransactionManager"对事务进行管理，翻开 DataSourceTransactionManager的源码，我们看到 DataSourceTransactionManager继承了AbstractPlatformTransactionManager（抽象的事务管理器）， DataSourceTransactionManager 重写了其中的一些方法，具体每个方法的作用，限于篇幅 ，本文不再赘述 ，这里 《Spring技术内幕》学习笔记16——Spring具体事务处理器的实现 有详细的介绍。 在现有的项目中

一、概念 首先事务 是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。事务有 Atomic（原子性）、Consistency（一致性）、Isolation（隔离性）和Durability（持久性）四种特性，简称ACID四特性。 原子性 事务最基本的操作单元，要么全部成功，要么全部失败，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样。 一致性 事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。 隔离性 指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。 持久性 指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。 二、Transactional注解原理 spring 在扫描bean的时候会扫描方法上是否包含

1． Spring工作机制及为什么要用？ Spring 是一个开源框架，是为了解决企业应用程序开发复杂性而创建的。Spring既是一个AOP框架，也是一IOC容器。 SpringFramework的组成：Spring AOP，Spring DAO，Spring ORM，Spring Web，Spring Context， Spring Web MVC。 Spring的核心就是IOC和AOP，所以Spring的工作机制简单的理解也就是IOC和AOP的工作机制。 借助于Spring AOP，Spring IoC能够很方便的使用到非常健壮、灵活的企业级服务，通过使用IoC能够降低组件之间的耦合度，最终，能够提高类的重用性，利于测试，而且更利于整个产品或系统集成和配置。 2． 说说AOP和IOC的概念以及在spring中是如何应用的? AOP，Aspect Oriented Program，面向(方面)切面的编程； IOC，Invert Of Control，控制反转。 简单说一下，IOC就是其实就是依赖注入，即用接口编程，在程序中不出现new关键字，而是用接口来命名引用，然后通过某种方式把接口的某个实现类的实例注入到引用里，从而实现接口与具体实现类的松耦合。 由容器控制程序之间的关系(通过XML配置)，而非传统实现中的由程序代码直接操控，(在一个Class对象中引用另一个Class对象时

前一阵子大概的看了一下seata分布式事务at模式的工作原理，那么现在就来记录一下它的工作方式。 这个项目调试起来还是挺麻烦的，因为你首先需要启动注册中心和seata管理服务，并且需要三个客户端来模拟分布式事务的进行，项目结构如下（盗图一张） tc:seata提供的事务管理中心。 tm:事务的发起者，并且最终与tc通信告诉事务的成功与否 rm:单个的微服务，也就是最终的资源管理者 实际上这张图不是很恰当，一般的业务流程中并不会有一个单独的business tm出现，实际上比较贴合的流程应该是在创建order的时候，会同时发起事务，并且最终会通过其它服务的返回信息，来决定提交来回滚，所以order服务应该即是tm又是rm，但是我又不会画图，那就这么着吧。 使用at模式，我们除了配置seata相关参数，数据源代理之外。只需要在需要进行事务控制的方法上加上@GlobalTranscation注解就可以了，那么看一下这个注解的代理方法，对于它的处理，在GlobalTransactionScanner这里做了处理，我们来重点看一下这个类。 首先看一下它的继承关系， public class GlobalTransactionScanner extends AbstractAutoProxyCreator implements InitializingBean,

声明式的事务处理中，要配置一个切面，即一组方法，如 Java代码 <!-- 声明式事务管理 --> <!-- 隔离级别配置--> <tx:advice id="txAdvice" transaction-manager="transactionManager"> <tx:attributes> <tx:method name="find*" propagation="SUPPORTS" read-only="true" /> <tx:method name="query*" propagation="SUPPORTS" read-only="true" /> <tx:method name="list*" propagation="SUPPORTS" read-only="true" /> <tx:method name="create*" propagation="REQUIRED" /> <tx:method name="save*" propagation="REQUIRED" /> <tx:method name="modify*" propagation="REQUIRED" /> <tx:method name="update*" propagation="REQUIRED" /> <tx:method name="delete*" propagation=