事务回滚

1、遇到的问题 　　当我们一个方法里面有多个数据库保存操作的时候，中间的数据库操作发生的错误。伪代码如下： public method() { Dao1.save(Person1); Dao1.save(Person2); Dao1.save(Person2);//假如这句发生了错误，前面的两个对象会被保存到数据库中 Dao1.save(Person2); } 　　期待的情况：发生错误之前的 所有数据库保存操作都回滚 ，即不保存 　　正常情况：前面的数据库操作会被执行，而发生数据库操作错误开始及之后的所有的数据保存操作都将失败。这样子应该都不是我们要的结果吧。 　　当遇到这种情况，我们就可以使用Spring的事务解决这个问题。 2、异常的一些基本知识 1) 异常的架构 　　异常的继承结构：Throwable为基类，Error和Exception继承Throwable，RuntimeException和IOException等继承Exception。Error和RuntimeException及其子类成为未检查异常（unchecked），其它异常成为已检查异常（checked）。 2）Error异常 　　Error表示程序在运行期间出现了十分严重、不可恢复的错误，在这种情况下应用程序只能中止运行，例如JAVA 虚拟机出现错误。Error是一种unchecked Exception

回滚段 可以说是用来保持数据变化前映象而提供一致读和保障事务完整性的一段磁盘存储区域。当一个事务开始的时候，会首先把变化前的数据和变化后的数据先写入日志缓冲区，然后把变化前的数据写入回滚段，最后才在数据缓冲区中修改（日志缓冲区内容在满足一定的条件后可能被写入磁盘，但在事务提交的时候日志必须写入磁盘，而数据缓冲区中的数据依赖于检查点的发生和DBWR进程的活动） Rollback是一个代价昂贵的操作，如果一个系统的事务回退率过高，应该检查系统是否正常或者程序设计思路是否存在问题。查询数据库启动依赖的 事务回退率，如果发现太高，一定要引起重视。 --查询回退率的sql SELECT NAME, VALUE FROM v$sysstat WHERE NAME IN ('user commits', 'transaction rollbacks'); 关于回滚段的数据，如果是delete操作，则回滚段将回记录整个行的数据；如果是update，则只记录被修改了的字段的变化前的数据（前映像）；如果是insert，则只记录插入记录的rowid。所以，假如commit，那么回滚段中简单标记该事务已经提交；假如rollback，则操作是 delete的话，把回滚段中的数据重新写回数据块，操作是update的话则把变化前的数据修改回去，操作是insert的话则根据rowid把该记录删除

　　事务全部是关于原子性的。原子性是指可以把一些事情当做一个单元来看待。从数据库的角度看，它是指应全部执行或全部都不执行的一条或多条语句的最小组合。 　　事务要有非常明确的开始和结束点。SQL Server中的每一条SELECT、INSERT、UPDATE和DELETE语句都是隐式事务的一部分。即使只发出一条语句，也会把这条语句当做一个事务。但是如果需要的不只是一条，可能是多条语句呢？在这种情况下，就需要有一种方法来标记事务的开始和结束，以及事务的成功或失败。可以使用一些T-SQL语句在事务中"标记"这些点。 　　BEGIN TRAN:设置起始点。 　　COMMIT TRAN:使事务成为数据库中永久的、不可逆转的一部分。 　　ROLLBACK TRAN:本质上说想要忘记它曾经发生过。 　　SAVE TRAN:创建一个特定标记符，只允许部分回滚。 一、事务语法 　　1、BEGIN TRAN 　　事务的开始可能是事务过程中最容易理解的概念。它唯一的目的就是表示一个单元的开始。如果由于某种原因，不能或者不想提交事务，那么这就是所有数据库活动将要回滚的起点。也就是说，数据库会忽略这个起点之后的最终没有提交的所有语句。 　　语法如下： BEGIN TRAN[SACTION] [ <transaction name> | <@transaction variable> ] 　　[ WITH

导语 上篇我们对 Transactional 注解进行了详细的解释，还没看的小伙伴，快看过来 https://blog.csdn.net/weixin_38937840/article/details/103939034 ，本节我们将对事务的使用与回滚进行演示！ Transactional 事务使用与回滚策略 @Transactional public void save ( ) { Demo demo = Demo.builder ( ) .id ( uid ( )) .name ( "javayh" ) .adder ( "beijing" ) .build ( ) ; demoDao.save ( demo ) ; } 我们启动项目，进行接口调用，进行一个简单的插入，小编为了方便这次使用的是JPA，下面我们看一执行的过程； 从下图我们可以看出， 首先Spring为我创建了默认的事务，并进行了默认配置，还不了接的请看上篇的现象介绍 之后进行了数据库的操作，这是我的代码执行完成，没有任何的异常 最后进行了事务的提交和关闭 然后我对上面的代码进行修改 @Transactional public void save ( ) { Demo demo = Demo.builder ( ) .id ( uid ( )) .name ( "javayh" ) .adder (

spring事务失效场景 添加@Transactional后的方法，不会直接操作数据库，例如保存方法，在执行完保存语句后，数据库并没有出现该数据，只有方法结束之后，才会正式保存到数据库。 1 、首先使用如下代码 确认你的bean 是代理对象吗？ 必须是Spring定义（通过XML或注解定义都可以）的Bean才接受事务。 直接new出来的对象添加事务是不起作用的。 可以通过以下方式判断是否是代理对象： AopUtils.isAopProxy(Object object) AopUtils.isCglibProxy(Object object) //cglib AopUtils.isJdkDynamicProxy(Object object) //jdk动态代理； 2 、如使用mysql且引擎是MyISAM，则事务会不起作用，原因是MyISAM不支持事务，可以改成InnoDB； 3 、@Transactional 注解只能应用到 public 可见度的方法上。 如果你在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不会报错，事务也会失效。这一点由Spring的AOP特性决定的； 4 、如果你使用了springmvc，可能是context:component-scan重复扫描引起的； 5

1 分布式事务背景 随着分布式数据库技术的发展越来越成熟，业内对于分布式数据库的要求也由曾经只用满足解决海量数据的存储和读取这类边缘业务向核心交易业务转变。分布式数据库如果要满足核心账务类交易需求，则其需要完善分布式事务，向传统关系型数据库看齐。即分布式事务的实现也需要像传统关系型数据库的事务一样满足事务的标准要求及定义，即ACID特征。 分布式数据库的数据是进行多机器多节点分散存储的，这样的存储架构为实现分布式事务带来了极大的难度。数据事务操作时，事务操作会结合数据分布情况，到不同的存储位置上去执行，而这个存储位置位于网络中的不同机器的不同磁盘上。 2 事务基本概念 2.1 事务使用场景 银行应用是一个经典案例，可以解释事务应用的必要性。假设银行数据库有两张表，支票账户表（check）和存款账户表（save）。现在要从LiLei的支票账户里转账200元到她的存款账户，那么需要至少完成3步操作： 检查支票存款账户的余额是否大于200元； 从支票存款账户余额中减去200元； 在存款账户余额中增加200元； 所有的操作被打包在一个事务里执行，如果某一步失败，就回滚所有已完成步骤。事务操作一般用 START TRANSACTION 语句开始一个事务，用 COMMIT 语句提交整个事务，永久地修改数据，或者用 ROLLBACK 语句回滚整个事务，取消已做的修改。事务SQL操作样例如下：

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 事务（Transaction）是并发控制的基本单位。所谓的事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。例如，银行转账工作：从一个账号扣款并使另一个账号增款，这两个操作要么都执行，要么都不执行。所以，应该把它们看成一个事务。事务是数据库维护数据一致性的单位，在每个事务结束时，都能保持数据一致性。 针对上面的描述可以看出，事务的提出主要是为了解决并发情况下保持数据一致性的问题。 事务具有以下4个基本特征。 ● Atomic（原子性）：事务中包含的操作被看做一个逻辑单元，这个逻辑单元中的操作要么全部成功，要么全部失败。 ● Consistency（一致性）：只有合法的数据可以被写入数据库，否则事务应该将其回滚到最初状态。 ● Isolation（隔离性）：事务允许多个用户对同一个数据进行并发访问，而不破坏数据的正确性和完整性。同时，并行事务的修改必须与其他并行事务的修改相互独立。 ● Durability（持久性）：事务结束后，事务处理的结果必须能够得到固化。 2.事务的语句 　开始事物：BEGIN TRANSACTION 　提交事物：COMMIT TRANSACTION 　回滚事务：ROLLBACK TRANSACTION 3.事务的4个属性 ①原子性(Atomicity)

因为在业务层调用了 try{}catch(){} 并且异常没有在catch处抛出来，所以spring aop的事务不起作用 Spring AOP异常捕获原理： 被拦截的方法，须显式的抛出异常，且不能做任何处理，这样AOP才能捕获到方法中的异常，进而进行回滚。 换句话说，就是在Service层的方法中，不需要使用 try...catch 或者在catch中的最后加上 throw new RuntimeException(); 这样程序才会被AOP捕获，进而进行回滚。 来源： https://www.cnblogs.com/west-iversion/p/12173662.html

1： PROPAGATION_REQUIRED 加入当前正要执行的事务不在另外一个事务里，那么就起一个新的事务。比如说，ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于执行ServiceA.methodA的时候，ServiceA.methodA已经起了事务，这时调用ServiceB.methodB，ServiceB.methodB看到自己已经运行在ServiceA.methodA的事务内部，就不再起新的事务。而假如ServiceA.methodA运行的时候发现自己没有在事务中，他就会为自己分配一个事务。 这样，在ServiceA.methodA或者在ServiceB.methodB内的任何地方出现异常，事务都会被回滚。即使ServiceB.methodB的事务已经被提交，但是ServiceA.methodA在接下来fail要回滚，ServiceB.methodB也要回滚。 2： PROPAGATION_SUPPORTS 如果当前在事务中，即以事务的形式运行，如果当前不再一个事务中，那么就以非事务的形式运行。 3： PROPAGATION_MANDATORY 必须在一个事务中运行。也就是说，他只能被一个父事务调用。否则，他就要抛出异常。 4： PROPAGATION_REQUIRES_NEW 比如我们设计ServiceA

前言 fescar发布已有时日，分布式事务一直是业界备受关注的领域，fescar发布一个月左右便受到了近5000个star足以说明其热度。当然，在fescar出来之前，已经有比较成熟的分布式事务的解决方案开源了，比较典型的方案如LCN（https://github.com/codingapi/tx-lcn）的2pc型无侵入事务，目前lcn已发展到5.0，已支持和fescar事务模型类似的TCX型事务。还有如TCC型事务实现hmily（https://github.com/yu199195/hmily）、tcc-transaction(https://github.com/changmingxie/tcc-transaction)等。在微服务架构流行的当下、阿里这种开源大户背景下，fescar的发布无疑又掀起了研究分布式事务的热潮。fescar脱胎于阿里云商业分布式事务服务GTS，在线上环境提供这种公共服务其模式肯定经受了非常严苛的考验。其分布式事务模型TXC又仿于传统事务模型XA方案，主要区别在于资源管理器的定位一个在应用层一个在数据库层。博主觉得fescar的txc模型实现非常有研究的价值，所以今天我们来好好翻一翻fescar项目的代码。本文篇幅较长，浏览并理解本文大概耗时30~60分钟左右。 项目地址 fescar：https://github.com/alibaba