事务回滚

微信公众号【黄小斜】大厂程序员，互联网行业新知，终身学习践行者。关注后回复「Java」、「Python」、「C++」、「大数据」、「机器学习」、「算法」、「AI」、「Android」、「前端」、「iOS」、「考研」、「BAT」、「校招」、「笔试」、「面试」、「面经」、「计算机基础」、「LeetCode」 等关键字可以获取对应的免费学习资料。 ​ 事务的概念 事务指逻辑上的一组操作，组成这组操作的各个单元，要不全部成功，要不全部不成功。 例如：A向B转账100元，对应于如下两条sql语句： update from account set money=money+100 where name='b'; update from account set money=money-100 where name='a'; 1 2 1 2 数据库 默认事务是自动提交的，也就是发一条sql它就执行一条，如果想多条sql放在一个事务中执行，则需要使用如下语句： start transaction … … commit 1 2 3 4 1 2 3 4 数据库开启事务命令： start transaction ：开启事务 rollback ：回滚事务 commit ：提交事务 MySQL数据库中操作事务命令 编写 测试 SQL脚本，如下： /* 创建数据库 */ create database day16

文章目录 一、事务的隔离级别 二、事务隔离的实现 三、幻读 1.幻读是什么 2.幻读有什么问题 3.如何解决幻读 思考题 一、事务的隔离级别 提到事务，你肯定会想到 ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性），隔离级别就是“隔离性”的具体体现。 当数据库上有多个事务同时执行的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题。 脏读 ：当数据库中一个事务A正在修改一个数据但是还未提交或者回滚，另一个事务B 来读取了修改后的内容并且使用了， 之后事务A提交了，此时就引起了脏读。 此情况仅会发生在： 读未提交的的隔离级别. 不可重复读 ：在一个事务A中多次操作数据，在事务操作过程中(未最终提交)，事务B也才做了处理，并且该值发生了改变，这时候就会导致A在事务操作的时候，发现数据与第一次不一样了。 就是不可重复读。 此情况仅会发生在：读未提交、读提交的隔离级别. 幻读 ：事务a 开启, 查询符合条件的数据 ,发现有10条, 准备将这10条记录修改, 此时事务b开启, 插入了一条符合事务a查询条件的记录. 提交事务, 回到事务a, a也提交事务, 当再次查询到时候, 发现修改了11条。感觉发生了幻觉一样. 此为幻读.

3种事务模型 本地事务模型 本地事务模型的名称来自于它实际上不是管理事务的框架，而是本地资源管理器。资源管理器是与之通信的数据源的实际提供者。例如，对于数据库，资源管理器是通过数据库驱动程序和DBMS实现的。对于JMS，资源管理器是通过特定的JMS提供程序实现的队列（或主题）连接工厂。使用本地事务模型，开发人员管理连接，而不是事务。实际管理本地事务的是DBMS或JMS提供程序。关于本地事务， 事实是事务管理由底层数据库(DBMS)处理，如果是jms，则由底层消息传递提供程序处理。从开发人员的角度来看，我们不管理本地事务模型中的事务，而是管理连接 。下面的代码示例演示了使用直接JDBC代码的本地事务模型的使用： public void updateTradeOrder(TradeOrderData order) throws Exception { DataSource ds = (DataSource) (new InitialContext()).lookup( "jdbc/MasterDS"); Connection conn = ds.getConnection(); conn.setAutoCommit(false); Statement stmt = conn.createStatement(); String sql = "update trade_order ...

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

事物管理对于企业应用来说是至关重要的，好使出现异常情况，它也可以保证数据的一致性。 spring 支持编程式事务管理和声明式事务管理两种方式。 编程式事务管理使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。 声明式事务管理建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明(或通过基于@Transactional注解的方式)，便可以将事务规则应用到业务逻辑中。 显然声明式事务管理要优于编程式事务管理，这正是spring倡导的非侵入式的开发方式。声明式事务管理使业务代码不受污染，一个普通的POJO对象，只要加上注解就可以获得完全的事务支持。和编程式事务相比，声明式事务唯一不足地方是，后者的最细粒度只能作用到方法级别，无法做到像编程式事务那样可以作用到代码块级别。但是即便有这样的需求，也存在很多变通的方法，比如，可以将需要进行事务管理的代码块独立为方法等等。 声明式事务管理也有两种常用的方式

@Transactional注解 一.事物传播行为介绍: @Transactional(propagation=Propagation.REQUIRED) ：如果有事务, 那么加入事务, 没有的话新建一个(默认情况下) 　　@Transactional(propagation=Propagation.NOT_SUPPORTED) ：容器不为这个方法开启事务 　　@Transactional(propagation=Propagation.REQUIRES_NEW) ：不管是否存在事务,都创建一个新的事务,原来的挂起,新的执行完毕,继续执行老的事务 　　@Transactional(propagation=Propagation.MANDATORY) ：必须在一个已有的事务中执行,否则抛出异常 　　@Transactional(propagation=Propagation.NEVER) ：必须在一个没有的事务中执行,否则抛出异常(与Propagation.MANDATORY相反) 　　@Transactional(propagation=Propagation.SUPPORTS) ：如果其他bean调用这个方法,在其他bean中声明事务,那就用事务.如果其他bean没有声明事务,那就不用事务. 二.事物超时设置: @Transactional(timeout=30) /

学习存储过程中使用断点回滚事务时，发现目前网络上存在一个问题，那就是使用断点回滚后，都忘记了一个很重要的事情，提交事务。虽然使用了断点回滚，但是断点回滚不像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

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

分布式事务之解决方案（XA和2PC） https://zhuanlan.zhihu.com/p/93459200 ​ 博彦信息技术有限公司 java工程师 3. 分布式事务解决方案之2PC（两阶段提交） 针对不同的分布式场景业界常见的解决方案有2PC、TCC、可靠消息最终一致性、最大努力通知这几种。 3.1. 什么是2PC 2PC即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两阶段，P是指准备阶段，C是提交阶段。 举例 ：张三和李四好久不见，老友约起聚餐，饭店老板要求先买单，才能出票。这时张三和李四分别抱怨近况不如意，囊肿羞涩，都不愿意请客，这时只能AA。只有张三和李四都付款，老板才能出票安排就餐。但由于张三和李四都是铁公鸡，形成两尴尬的一幕 ： 准备阶段 ：老板要求张三付款，张三付款。老板要求李四付款，李四付款。 提交阶段 ：老板出票，两人拿票纷纷落座就餐。 例子中形成两一个事务，若张三或李四其中一个拒绝付款，或钱不够，店老板都不会给出票，并且会把已收款退回。 整个事务过程由事务管理器和参与者组成，店老板就是事务管理器，张三、李四就是事务参与者，事务管理器负责决策整个分布式事务的提交和回滚，事务参与者负责自己本地事务的提交和回滚。 在计算机中部分关系数据库如Oracle

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参数就可以设置自动管理回滚段特性。