回滚

详见：https://www.cnblogs.com/softidea/p/5877546.html Spring Boot 使用事务非常简单，首先使用注解 @EnableTransactionManagement 开启事务支持后，然后在访问数据库的Service方法上添加注解 @Transactional 便可。 关于事务管理器，不管是JPA还是JDBC等都实现自接口 PlatformTransactionManager 如果你添加的是 spring-boot-starter-jdbc 依赖，框架会默认注入 DataSourceTransactionManager 实例。如果你添加的是 spring-boot-starter-data-jpa 依赖，框架会默认注入 JpaTransactionManager 实例。 你可以在启动类中添加如下方法，Debug测试，就能知道自动注入的是 PlatformTransactionManager 接口的哪个实现类。 @EnableTransactionManagement // 启注解事务管理，等同于xml配置方式的 <tx:annotation-driven /> @SpringBootApplication public class ProfiledemoApplication { @Bean public Object

什么场景下会产生分布式事务？ 在支付异步回调的情况下，支付宝发送http请求给第三方平台，第三方平台需要更改支付状态以及订单状态，在此场景下，第三方平台更改本地支付数据库的支付状态后，通知订单服务更改订单的状态，在此程序后，如果代码出现异常，由于有声明式事务的存在，本地支付服务的数据库会进行回滚，变成未支付状态，但是订单服务的状态却无法回滚，订单服务的订单的状态变成已支付状态，这就出现了订单数据库和支付数据库数据不一致的情况，这便是分布式事务产生的场景之一。 什么是分布式事务？ 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 分布式事务的理论 1、cap理论 1）数据一致性（consistency） 如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据，对调用者而言数据具有强一致性(strong consistency) (又叫原子性 atomic、线性一致性 linearizable consistency) 一致性指

@Transactional ----------------------------------------------------------------------------------------------------------------------------- 通过AOP，在方法执行时控制事务 事务基本要素 原子性 (Atomicity): 事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。 一致性 (Consistency): 事务开始前和结束后，数据库的完整性约束没有被破坏。比如A向B转账，不可能A扣了钱，B却没收到。 隔离性 (Isolation): 同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。 持久性 (Durability): 事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。 用法： 需要回滚不要在测试方法上使用@Rollback，用@Transactional即可 如果采用了读写分离配置，那么千万不要在测试查询的方法上加回滚事务标记，否则只会经过写库

在 关于分布式事务的理解 一文中，最后留了一个坑是关于TCC框架的。当时由于时间问题耽搁了，最近总算有时间把这个坑填上了。 本文会大致介绍下两阶段和三阶段提交，以及TCC模式。 分布式事务分为 两阶段型 补偿型 异步确保型 最大努力通知型几种 上文我们已近介绍了 异步确保型 和 最大努力通知 这两种服务模式的具体应用，接下来介绍下剩下两种。 两阶段提交（2PC）型 两阶段型：就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS。 准备阶段 事务协调者(事务管理器)给每个参与者(资源管理器)发送Prepare消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态。 可以进一步将准备阶段分为以下三个步骤： 协调者节点向所有参与者节点询问是否可以执行提交操作(vote)，并开始等待各参与者节点的响应。 参与者节点执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。 （注意：若成功这里其实每个参与者已经执行了事务操作） 各参与者节点响应协调者节点发起的询问。如果参与者节点的事务操作实际执行成功， 则它返回一个”同意”消息；如果参与者节点的事务操作实际执行失败，则它返回一个”中止”消息。 提交阶段 如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚

学习存储过程中使用断点回滚事务时，发现目前网络上存在一个问题，那就是使用断点回滚后，都忘记了一个很重要的事情，提交事务。虽然使用了断点回滚，但是断点回滚不像rollBack或commit一样结束当前事务，而使用断点回滚只会回滚到声明断点的地方，之前的产生的事务仍需要提交的，如果不提交，事务一直在数据库中缓存. 保存点(SAVEPOINT)是事务处理过程中的一个标志，与回滚命令(ROLLBACK)结合使用，主要的用途是允许用户将某一段处理回滚而不必回滚整个事务。 如果定义了多个savepoint，当指定回滚到某个savepoint时，那么回滚操作将回滚这个savepoint后面的所有操作（即使后面可能标记了N个savepoint）。 例如，在一段处理中定义了五个savepoint，从第三个savepoint回滚，后面的第四、第五个标记的操作都将被回滚，如果不使用ROLLBACK TO savepoint_name而使用ROLLBACK，将会滚整个事务处理。 一旦执行了rollback那么savepoint的操作都将撤消，当然最后一定执行一次commit，否则所有的操作都是在缓存中进行的，不会真正的写入数据库中。 --起一个名字为A的savepoion savepoint A(这个A是savepoint的名字) --跳转到savepoint A处 rollback to A

TX-LCN的3种模式 LCN5.0.2有3种模式，分别是LCN模式，TCC模式，TXC模式 LCN模式： LCN模式是通过代理Connection的方式实现对本地事务的操作，然后在由TxManager统一协调控制事务。当本地事务提交回滚或者关闭连接时将会执行假操作，该代理的连接将由LCN连接池管理。 该模式的特点： - 该模式对代码的嵌入性为低。 - 该模式仅限于本地存在连接对象且可通过连接对象控制事务的模块。 - 该模式下的事务提交与回滚是由本地事务方控制，对于数据一致性上有较高的保障。 - 该模式缺陷在于代理的连接需要随事务发起方一共释放连接，增加了连接占用的时间。 TCC模式： TCC事务机制相对于传统事务机制（X/Open XA Two-Phase-Commit），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。主要由三步操作，Try: 尝试执行业务、 Confirm:确认执行业务、 Cancel: 取消执行业务。 该模式的特点： - 该模式对代码的嵌入性高，要求每个业务需要写三种步骤的操作。 - 该模式对有无本地事务控制都可以支持使用面广。 - 数据一致性控制几乎完全由开发者控制，对业务开发难度要求高。 TXC模式： TXC模式命名来源于淘宝，实现原理是在执行SQL之前，先查询SQL的影响数据

我们从一个用户请求开始讲，ORACLE的完整的工作机制是怎样的，首先一个用户进程发出一个连接请求，如果使用的是主机命名或者是本地服务命中的主机名使用的是机器名(非IP地址)，那么这个请求都会通过DNS服务器或HOST文件的服务名解析然后传送到ORACLE监听进程，监听进程接收到用户请求后会采取两种方式来处理这个用户请求，下面我们分专用服务器和共享服务器分别采用这两种方式时的情况来讲： 专用服务器模式下： 一种方式是监听进程接收到用户进程请求后，产生一个新的专用服务器进程，并且将对用户进程的所有控制信息传给此服务器进程，也就是说新建的服务器进程继承了监听进程的信息，然后服务器进程给用户进程发一个RESEND包，通知用户进程可以开始给它发信息了，用户进程给这个新建的服务器进程发一个CONNECT包，服务器进程再以ACCEPT包回应用户进程，致此，用户进程正式与服务器进程确定连接。我们把这种连接叫做HAND-OFF连接，也叫转换连接。 另一种方式是监听进程接收到用户进程的请求后产生一个新的专用服务器进程，这个服务器进程选用一个TCP/IP端口来控制与用户进程的交互，然后将此信息回传给监听进程，监听进程再将此信息传给用户进程，用户进程使用这个端口给服务器进程发送一个CONNECT包，服务器进程再给用户进程发送一个ACCEPT包，致此，用户进程可以正式向服务器进程发送信息了

undo_retention简单定义，就是最多数据的最少保留时间。AUM模式下，undo_retention参数用于事务commit后undo数据保留的时间。单位为秒。这是个no guarantee的限制。也就是，若空间足够，他只是个‘花瓶’；当可用空间不足而又有事务需要回滚空间，则这些数据依然会被覆盖。这个行为可能会导致ORA-01555错误，这些数据被记忆的时间可用v$undostat里面的字段TUNED_UNDORETENTION来查询。 UNDO主要用于以下方面： 1.在执行rollback语句的时候rollback事物 2.恢复数据库 3.提供读一致性 4.为oracle flashback query提供支持 5.使用oracle flashback特性恢复数据库逻辑失败 一般来讲事物的undo信息存储在回滚段中，事物的undo信息一直存在，直到一个commit或者rollback语句执行。自动回滚段管理允许DBA指定oracle数据库保留多久的commit之后的undo信息。防止在长时间的查询产生ora-01555：snapshot too old.通过设置UNDO_RETENTION参数来达到这个目的，默认是900s(15min).可以设置这个参数保证数据库保留undo日志的时间.设置UNDO_MANAGEMENT = AUTO参数就可以设置自动管理回滚段特性。

问题场景 什么是事务? 事务是数据库从一个稳定状态变迁到另一个稳定状态的保证，具备 ACID 这 4 个特性： 原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态。 一致性（Consistency）：在事务开始之前和事务结束以后，数据库的完整性限制没有被破坏。 隔离性（Isolation）：两个事务的执行是互不干扰的，两个事务时间不会互相影响。 持久性（Durability）：在事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中，并且是完全的。 例如应用程序需要更新多条相关数据时就需要进行事务处理。 什么是分布式事务? 当遇到复杂业务调用时，可能会出现跨库多资源调用(一个事务管理器，多个资源)/多服务调用（多个事务管理器，多个资源），期望全部成功或失败回滚，这就是分布式事务，用以保证“操作多个隔离资源的数据一致性”。 分布式事务与 XA 规范 分布式事务是指会涉及到操作多个数据库的事务，同样必须保证 ACID。其就是将对同一库事务的概念扩大到了对多个库的事务：对同一库的 SQL 操作对应了分布式事务中对一个库的事务。 X/Open XA 定义了分布式事务处理的规范，并由数据库厂商在驱动层面进行实现。XA 规范的基础是两阶段提交协议

Spring事务管理分为 声明式事务管理 和 编程式事务 管理，声明式事务管理又分为 xml 和 注解 两种配置方式。应该优先选择声明式事务，因为声明式事务对程序代码的影响最小，因此最符合 非侵入式轻量级容器 的理想 。只有在进行少量事务操作时，才应该选择编程式事务管理的方式。 声明式事务管理 xml配置方式 Spring配置文件： <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation=" http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans