回滚

RuntimeException()和Exception()区别： 1.继承自RuntimeException或error的是非检查型异常，而继承自exception的则是检查型异常（当然，runtimeexception本身也是exception的子类）。 2.对非检查型类异常可以不用捕获，而检查型异常则必须用try语句块进行处理或者把异常交给上级方法处理总之就是必须写代码处理它。所以必须在service捕获异常，然后再次抛出，这样事务方才起效。 Spring事务默认只在发生未被捕获的RuntimeException()时才进行回滚。 Spring通过SpringAOP进行声明式事务管理： 　　SpringAOP异常捕获的原理：被拦截的方法需显式抛出异常，并不能经任何处理，这样aop代理才能捕获到方法的异常，才能进行回滚， 默认情况下SpringAOP只捕获RuntimeException的异常，因此不是RuntimeException或其子类的异常不能够捕获，默认情况下不进行回滚， 但可以通过配置来捕获特定的异常并回滚 。 因此： 方法1： 在service层不使用try......catch或者在catch中最后加上throw new RuntimeException()，这样程序异常时aop才可以捕获异常并进行回滚。 最终在service上层（如controller层

1、备份 　　备份可以使用批处理命令解决，实际就是复制当前发布文件 ::备份文件夹名，使用当前时间 set foldername=%date:~0,4%%date:~5,2%%date:~8,2%%time:~0,2%%time:~3,2%%time:~6,2% ::发布目录 set publishfolder=D:\LastOne\PcApi ::文件夹不存在 创建 if not exist "%publishfolder%\Backup\" ( md "%publishfolder%\Backup" ) ::创建备份文件夹 md "%publishfolder%\Backup\%foldername%" ::复制当前发布文件到备份文件夹中，排除掉备份文件及日志文件 "C:\Windows\System32\robocopy.exe" %publishfolder%\. %publishfolder%\Backup\%foldername%\ /IS /e /XD Backup wwwroot 　　这一段加到发布命令前，在发布之前，对当前的发布文件备份 2、回滚 　　首先我们需要添加一些构建参数 　　是否回滚 　　再添加一个选择备份的下拉框，由于需要动态获取备份文件夹的名字，需要借助一些插件来实现 　　 添加Active Choices Plug-in插件，然后添加Active

二、保存点 Savepoint （断点回滚） 保存点是事务中的标记，从原理实现上来说是一个类似存储结构的类。可以回滚部分事务，而不是完整事务，同时会保存部分事务。python后端程序可以使用保存点。 一旦打开事务atomic()，就会构建一系列等待提交或回滚的数据库操作。通常，如果发出回滚命令，则会回滚整个事务。保存点则提供了执行 细粒度回滚 的功能，而不是将执行的完全回滚transaction.rollback()。 工作原理：savepoint通过对返回sid后面的将要执行的数据库操作进行计数，并保存在内置的列表中，当对数据库数据库进行操作时遇到错误而中断，根据sid寻找之前的保存点并回滚数据，并将这个操作从列表中删除。 相关API: 1. savepoint（using = None） 创建一个 新的 保存点。这表示处于正常状态的事务的一个点。返回保存点ID（sid）。在一个事务中可以创建多个保存点。 2. savepoint_commit（sid，using = None） 发布保存点sid，从创建保存点开始执行的数据库操作将成为可能回滚事务的一部分 3. savepoint_rollback（sid，using = None） 将事务回滚到保存点sid 4. clean_savepoints（using = None） 重置用于生成唯一保存点ID的计数器 值得注意的是：

4. 分布式事务解决方案之TCC 4.1. 什么是TCC事务 TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作 ：预处理Try、确认Confirm、撤销Cancel。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作既回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行失败，TM会进行重试。 分支事务失败的情况 ： TCC分为三个阶段 ： Try阶段是做业务检查（一致性）及资源预留（隔离），此阶段仅是一个初步操作，它和后续的Confirm一起才能真正构成一个完整的业务逻辑。 Confirm阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行Confirm。通常情况下，采用TCC则认为Confirm阶段是不会出错的。即 ：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。 Cancel阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了

转： https://www.cnblogs.com/sunny-sl/p/11236280.html 1. git本地版本回退 Git reset --hard commit_id(可用 git log –oneline 查看) 2. git远程版本回退 git push origin HEAD --force #远程提交回退 下面的命令也可以实现远程版本回退 git reset --hard HEAD~1 git push --force 3. git reverse和git reset的区别 git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。 在回滚这一操作上看，效果差不多。但是在日后继续merge以前的老版本时有区别。因为git revert是用一次逆向的commit“中和”之前的提交，因此日后合并老的branch时，导致这部分改变不会再次出现，但是git reset是之间把某些commit在某个branch上删除，因而和老的branch再次merge时，这些被回滚的commit应该还会被引入。 git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。 git reset +

今天我在写代码的时候，看到了。一个注解@Transactional(rollbackFor = Exception.class)，今天就和大家分享一下，这个注解的用法； 如下图所示，我们都知道Exception分为运行时异常RuntimeException和非运行时异常 error是一定会回滚的 如果不对运行时异常进行处理，那么出现运行时异常之后，要么是线程中止，要么是主程序终止。 如果不想终止，则必须捕获所有的运行时异常，决不让这个处理线程退出。队列里面出现异常数据了，正常的处理应该是把异常数据舍弃，然后记录日志。不应该由于异常数据而影响下面对正常数据的处理。 非运行时异常是RuntimeException以外的异常，类型上都属于Exception类及其子类。如IOException、SQLException等以及用户自定义的Exception异常。对于这种异常，JAVA编译器强制要求我们必需对出现的这些异常进行catch并处理，否则程序就不能编译通过。所以，面对这种异常不管我们是否愿意，只能自己去写一大堆catch块去处理可能的异常。 事务管理方式 事务管理对于企业应用来说是至关重要的，即使出现异常情况，它也可以保证数据的一致性。 spring支持编程式事务管理和声明式事务管理两种方式。 　　

数据操纵语言DML（Data Manipulation Language），用户通过它可以实现对数据库的基本操作。 ========================== 1　插入数据 语法：INSERT INTO 表名(列名1,列名2, …) VALUES(值1, 值2) INSERT INTO stu(sid, sname,age,gender) VALUES('s_1001', 'pwc', 18, 'male'); 或者 INSERT INTO stu VALUES('s_1001', 'pwc', 18, 'male'); 语法：INSERT INTO 表名 VALUES(值1,值2,…) 因为没有指定要插入的列，表示按创建表时列的顺序插入所有列的值： INSERT INTO stu VALUES('s_1002', 'pwc', 18, 'male'); 　　注意：所有字符串数据必须使用单引用！ ========================== 2　修改数据 语法：UPDATE 表名 SET 列名1=值1, … 列名n=值n [WHERE 条件] UPDATE stu SET sname=’pwc’, age=’18’, gender=’male’ WHERE sid=’s_1001’; UPDATE stu SET sname=’pwc’, age=’18’

Oracle 1 TCL事务控制语言 1.1 提交 事务的提交比较简单；直接在执行DML语句后进行提交即可，如果不提交事务则刚刚通过DML语句进行修改的内容还未保存到数据库中，只在当前用户的连接会话中有效。要永久变更数据需要显示地执行提交、回滚或者退出当前回话（如退出sqlplus）。 提交的命令为：commit; 1.2 保存点与回滚 保存点savepoint一般与回滚rollback配合使用。在设置了savepoint后事务的粒度可以控制的更加细化，可以回滚到特定的保存点。 【语法】保存点savepoint SAVEPOINT <savepoint_name>; 【示例】 --创建一个保存点，名称为a savepoint a; 【注意】当创建保存点之后执行的DML操作，可以进行回滚，而保存点之前未提交的DML操作不受影响。 【语法】回滚 ROLLBACK [TO savepoint]; 【示例】 --回滚到保存点a,即在保存点a之后的所有未提交的DML都无效。 rollback to a; /*保存点与回滚完整示例*/ --1 、创建保存点a Savepoint a ; --2 、插入emp 数据 it1 Insert into emp ( empno , ename ) values ( 1234 , 'it1' ); --3 、创建保存点b savepoint b ; -

1.问题背景 刚来新公司不久，对业务还不太熟悉，所以领导先安排我维护原有系统。大概介绍下项目背景，项目分为核心业务部分在项目A中，与第三方交互的业务在项目B中，前端发起请求调用A项目接口，并在A项目中调用B项目接口，并在B项目中调用第三方获取数据（原有系统这样设计的）。 获取到第三方数据后判断数据库中是否有该记录（有唯一键），如有则执行更新操作，没有则新增。并且如果第三方认为该数据已失效，需要从数据库中删除(逻辑删除)，并返回第三方删除成功回调，后续便不会再查到已失效的数据。 对应流程图如下 在代码处理中对整个过程加事务@Transactional注解，即在对数据进行删除(逻辑删除，实际执行update语句)时会根据唯一索引对该行加锁。在生成环境B项目频繁出现Lock wait timeout exceeded; try restarting transaction 异常，经排查定位到该功能代码，排查代码发现该功能有如下代码 有经验的同学应该已经看出问题所在，这里将全局异常捕获，记录错误日志，但问题就出在catch这里，由于异常被catch吞噬，@Transactional无法拿到异常，所以不会执行rollback回滚，导致一直占用数据库行锁。(这里的异常是调用第三方接口失败，由于调用太频繁，第三方接口崩溃，这里后续也做了并发控制)

1.子线程抛出异常和主线程事务回滚 2.关于异步@Async + 事务@Transactional的结合使用问题分析 3.@Async和@Transactional失效原因 来源： https://www.cnblogs.com/thiaoqueen/p/11911308.html