事务回滚

版权声明：该文章仅作为个人记录分享，若有其他用途请注明出处。 【JCccc】 https://blog.csdn.net/qq_35387940/article/details/91494169 事务控制一般在一些比较重要的业务都需要考虑。 进入正题，关于事务Transactional 的要点以及使用方式： @Transactional 1.需要将使用事务注解的方法设置为public； 2.如果没有在注解后做异常配置，只会对手动抛出的 throw new RuntimeException() 起作用； 3.若想对其余异常起作用，则需做类似配置 @Transactional(rollbackOn = Exception.class) ； 4.手动回滚，在使用注解后，在需要执行事务回滚的地方，TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); （使用手动回滚，就不需要抛异常了） 很多时候往往抛出异常进行回滚后无法return或者做一些其余的逻辑，那么这种情况使用手动事务回滚是非常不错的。 转载请标明出处: Springboot 快速了解 事务回滚@Transactional 文章来源: https://blog.csdn.net/qq_35387940/article/details

明天再整理 分布式事务解决方案之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分为三个阶段： 1. Try 阶段是做业务检查(一致性)及资源预留(隔离)，此阶段仅是一个初步操作，它和后续的Confirm 一起才能真正构成一个完整的业务逻辑。 2. Confirm 阶段是做确认提交，Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用TCC则认为 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。 3. Cancel 阶段是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的

群里经常卧虎藏龙，转载一篇百度大牛，投稿原创文章，大家交流学习 ，欢迎更多朋友投稿，发布原创文章和干货和大家分享交流。 引言 在互联网系统中，理想的情况下，肯定是希望系统能够同时满足“一致性”、“可用性”和“分区容忍性”。 但是基于熟悉的CAP定律也好，还是BASE理论， 我们知道，在实际情况中是不可能实现的。而在金融领域，一致性是最为关注的特性，任何情况下都必须满足一致性。关于CAP定律和BASE理论，本文不再介绍，有兴趣的同学可以自行百度一下。本文重点来阐述下关于一致性的方案，包括强一致性和最终一致性。 而在互联网领域， 很多情况下都是牺牲强一致性，来达到高可用性， ϵ 统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。 数据库本地事务 数据库事务肯定是强一致性的方案，而且是一致性最简单的方案，因为一致性是数据库的事务来保证的，业务层不需要关心细节。比较典型的应用是在返现场景下，针对带有返现的交易的退款，需要一次性退两笔交易单，采用的就是通过数据库本地事务来完成的。具体如下： 用户A花了100元购买商户B的商品，购买结束后返现给用户A 2元。 这是两笔交易，原始交易是100元，返现交易是2元。 那么发生退款时，需要保证两笔交易同时都退款。这个就是直接采用数据库本地事务实现的，即一次退款请求，两笔交易同时退款。 总结： 数据库事务的优点是简单

本篇内容 什么是事务，它有什么用？ 事务的几个特性 事务常见操作指令详解 事务的隔离级别详解 脏读、不可重复读、可重复读、幻读详解 演示各种隔离级别产生的现象 关于隔离级别的选择 一、什么是事务？ 　　 数据库中的事务是指对数据库执行一批操作，这些操作最终要么全部执行成功，要么全部失败，不会存在部分成功的情况。 二、事务的几个特性(ACID)　　 　　原子性(Atomicity) 　　事务的整个过程如原子操作一样，最终要么全部成功，或者全部失败，这个原子性是从最终结果来看的，从最终结果来看这个过程是不可分割的。 　　一致性(Consistency) 　　事务开始之前、执行中、执行完毕，这些时间点，多个人去观察事务操作的数据的时候，看到的数据都是一致的，比如在事务操作过程中，A连接看到的是100，那么B此时也去看的时候也是100，不会说AB看到的数据不一样，他们在某个时间点看到的数据是一致的。 　　隔离性(Isolation) 　　一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。 　　持久性(Durability) 　　一个事务一旦提交，他对数据库中数据的改变就应该是永久性的。当事务提交之后，数据会持久化到硬盘，修改是永久性的。 三、Mysql中事务操作　　 　　mysql中事务默认是隐式事务

使用事务处理的话，需要数据库引擎支持事务处理。比如 MySQL 的 MyISAM 不支持事务处理，需要使用 InnoDB 引擎。 使用 transaction 方法操作数据库事务，当发生异常会自动回滚 1.手动控制事务 // 启动事务 Db::startTrans(); try{ $res = Db::table('user')->find(1); $rs = Db::table('user')->delete(1); if($res&&$rs){ // 提交事务 Db::commit(); } } catch (\Exception $e) { // 回滚事务 Db::rollback(); } 2.自动控制事务 Db::transaction(function(){ Db::table('user')->find(1); Db::table('user')->delete(1); }); 文章来源: ThinkPHP5事务回滚

这篇文章主要介绍 java Spring事务回滚 spring 事务回滚 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表示程序在运行期间出现了十分严重、不可恢复的错误，在这种情况下应用程序只能中止运行

@Override public BaseResponse transferStuPlan(GxyPlanTeacherStudentEntity teacherStudentEntity) { boolean stuIHaveJob = false; List<GxyPlanTeacherStudentEntity> deleteStu = new ArrayList<>(); for(String stuId:teacherStudentEntity.getStuIds()){ GxyPlanTeacherStudentEntity teacherStudentDto = planTeacherStudentMapper.selectPlanIdAndStuId(teacherStudentEntity.getPlanId(),stuId,teacherStudentEntity.getSnowFlakeId()); Integer countReport = reportService.countReport(reportEntity); if(countReport != null && countReport>0){ stuIHaveJob = true; break; } planTeacherStudentMapper.delete(new QueryWrapper

转载 Spring配置事务管理，service端通过@Transactional注解 使用步骤： 步骤一、在spring配置文件中引入<tx:>命名空间 <beans xmlns=”http://www.springframework.org/schema/beans” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:tx=”http://www.springframework.org/schema/tx” xsi:schemaLocation=”http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.0.xsd”> 步骤二、具有@Transactional 注解的bean自动配置为声明式事务支持 <tx:annotation-driven transaction-manager=”transactionManager” proxy-target-class=

异常: org.springframework.transaction.NoTransactionException: No transaction aspect-managed TransactionStatus in scope 执行的sql: UPDATE sys_config SET remark='1.准备升级 2. 升级成功 3. 升级失败 4. 升级中' WHERE c_key='update_statue'; ALTER TABLE `sys_config` ADD COLUMN `test` VARCHAR(50) NULL COMMENT 'test' AFTER `remark`; 环境: 类和方法上注解了 @Transactional(rollbackFor=Exception.class) , catch 异常处捕获异常时执行 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();//回滚 参考: https://blog.csdn.net/xuhaogang3/article/details/82190026 问题分析 : 1. 发现该类时 通过new Bean() 的构造方法的方式构造的,并没有托管个spring 所以 该类无法执行事务, 2. 或者多线程类 仅仅用

应用场景： 银行取钱，从ATM机取钱，分为以下几个步骤 1 登陆ATM机，输入密码； 2 连接数据库，验证密码； 3 验证成功，获得用户信息，比如存款余额等； 4 用户输入需要取款的金额，按下确认键； 5 从后台数据库中减掉用户账户上的对应金额； 6 ATM吐出钱； 7 用户把钱拿走。 对于上面的取钱这个事情，如果有一步出现错误的话，那么就会取消整个取钱的动作，但是如果在第5步，系统后台已经把钱减了，但是ATM机没有取出来，那么就应用到mysql中的事务。简单地 来说，就是取钱这7步要么都完成，要么就啥也不做，在数据库中就是这个道理。 事务是用户定义的一个数据库操作序列，这些操作要么全做要么全不做，是一个不可分割的工作单位，事务回滚是指将该事务已经完成的对数据库的更新操作撤销，在事务中，每个正确的原子 操作都会被顺序执行，直到遇到错误的原子操作。回滚的意思其实即使如果之前是插入操作的话，那么会执行删除之前插入的记录，如果是修改操作的话，那么会执行将update之前的记录还原。 因此，正确的原子操作是真正被执行过的，是物理执行。 事务是由一条或者多条sql语句组成，在事务的操作中，要么这些sql语句都执行，要么都不执行。 事务的ACID特性:原子性，一致性，隔离性，持久性。 在当前事务中确实能看到插入的记录，最后只不过被删除了，但是auto_increament不会删除而是改变值