事务回滚

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 ; -

１.@Transactional　　当标于类前时, 标示类中所有方法都进行事物处理 ２.@Transactional(propagation=Propagation.NOT_SUPPORTED) 　　当类中某些方法不需要事物时 ３.@Transactional(propagation=Propagation.REQUIRED) 　　如果有事务, 那么加入事务, 没有的话新建一个(默认情况下)４.@Transactional(propagation=Propagation.REQUIRES_NEW) 　　不管是否存在事务,都创建一个新的事务,原来的挂起,新的执行完毕,继续执行老的事务５.@Transactional(propagation=Propagation.MANDATORY) 　　必须在一个已有的事务中执行,否则抛出异常６.@Transactional(propagation=Propagation.NEVER) 　　在一个没有的事务中执行,否则抛出异常(与Propagation.MANDATORY相反)７.@Transactional(propagation=Propagation.SUPPORTS) 　　如果其他bean调用这个方法,在其他bean中声明事务,那就用事务.如果其他bean没有声明事务,那就不用事务.事务隔离级别:@Transactional

事务的定义 事务 ：数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作; 事务是一组不可再分割的操作集合（工作逻辑单元）。 典型事务使用场景 ：转账 update user_account set balance = balance - 1000 where userID = 3; update user_account set balance = balance + 1000 where userID = 1; MySQL 开启事务 ： /* BEGIN / START TRANSACTION --手工 COMMIT / ROLLBACK --事务提交或回滚 SET SESSION autocommit = ON/OFF --设定会话级别事务是否自动开启 */ MySQL 默认是开启事务的，通过 SHOW VARIABLES like 'autocommit'; 可以查看 MySQL 的事务开启情况。 在 autocommit = ON（自动提交事务）的情况下，可以执行 BEGIN; 或者 START TRANSACTION; 命令，改为手动提交事务，执行完 SQL 语句后，需要通过 COMMIT 命令提交事务，或者通过 ROLLBACK 命令回滚事务。 在 autocommit = OFF（手动提交事务）的情况下，执行完 SQL 语句后，需要通过 COMMIT

目录： 1.什么是事务？ 2.换个角度看事务 3.Java中的事务 4.啥又是分布式事务？ 5.分布式事务的几种实现思路 6.总结 写在前面 在分布式、微服务大行其道的今天，相信大家对这些名词都不会陌生。而说到使用分布式，或者拆分微服务的好处，你肯定能想到一大堆。 比如每个人只需要维护自己单独的服务，没有了以前的各种代码冲突。自己想测试、想发布、想升级，只需要care自己写的代码就OK了，很方便很贴心！ 然而事物都有两面性，但是它也同时也会带来的一些问题，今天的文章谈的就是分布式系统架构带来的其中一个棘手的问题： 分布式事务 1、什么是事务？ 首先抛出来一个问题：什么是事务？ 有人会说事务就是一系列操作，要么同时成功，要么同时失败；然后会从事务的ACID特性（原子性、一致性、隔离性、持久性）展开叙述。 确实如此，事务就是为了保证一系列操作可以正常执行，它必须同时满足ACID特性。 但是今天我们 换个角度思考下，我们不仅要知道what（比如什么是事务），更要知道事务的why（比如为什么会有事务这个概念？事务是为了解决什么问题）。 有时候，换个角度说不定有不一样的收获。 2、换个角度看事务 就像经典的文学作品均来自于生活，却又高于生活，事务的概念同样来自于生活，引入“事务”肯定是为了解决某种问题，不然，谁又愿意干这么无聊的事情呢？ 最简单最经典的例子： 银行转账

在业务接口中，一个方法嵌套了另外一个方法，2个方法上都加了@Transactional事务注解。 业务接口： @Service public class TransactionalTestServiceImpl implements TransactionalTestService { @Autowired private TransactionalTestHandle transactionalTestHandle; @Override @Transactional public void function() throws Exception { Pool record = new Pool(); transactionalTestHandle.executeTask(record); } } 嵌套方法 @Transactional(propagation = Propagation.REQUIRED, rollbackFor = {Exception.class}) public void executeTask(Pool record) throws ServiceException { if (record.getDocvalue() == null || (record.getDocvalue().compareTo(BigDecimal.valueOf(0)) ==

谈谈业务中使用分布式的场景 首先，需要了解系统为什么使用分布式。 随着互联网的发展，传统单工程项目的很多性能瓶颈越发凸显，性能瓶颈可以有几个方面： 1.应用服务层：随着用户量的增加，并发量增加，单项目难以承受如此大的并发请求导致的性能瓶颈。 2.底层数据库层：随着业务的发展，数据库压力越来越大，导致的性能瓶颈。 #场景1：应用系统集群的 Session 共享 应用系统集群最简单的就是服务器集群，比如：Tomcat 集群。应用系统集群的时候，比较凸显的问题是 Session 共享，Session 共享我们一是可以通过服务器插件来解决。另外一种也可以通过 Redis 等中间件实现。 #场景2：应用系统的服务化拆分 服务化拆分，是目前非常火热的一种方式。现在都在提微服务。通过对传统项目进行服务化拆分，达到服务独立解耦，单服务又可以横向扩容。服务化拆分遇到的经典问题就是分布式事务问题。目前，比较常用的分布式事务解决方案有几种：消息最终一致性、TCC 补偿型事务等。 #场景3：底层数据库的压力分摊 如果系统的性能压力出现在数据库，那我们就可以读写分离、分库分表等方案进行解决。 Session 分布式方案 #基于 nfs(net filesystem) 的 Session 共享 将共享服务器目录 mount 各服务器的本地 session 目录，session 读写受共享服务器 io 限制

MySQL 原理篇 MySQL 索引机制 MySQL 体系结构及存储引擎 MySQL 语句执行过程详解 MySQL 执行计划详解 MySQL InnoDB 缓冲池 MySQL InnoDB 事务 MySQL InnoDB 锁 MySQL InnoDB MVCC MySQL InnoDB 实现高并发原理 MySQL InnoDB 快照读在RR和RC下有何差异 转载： 《InnoDB并发如此高，原因竟然在这？》 并发控制 为啥要进行并发控制？ 并发的任务对同一个临界资源进行操作，如果不采取措施，可能导致不一致，故必须进行并发控制（Concurrency Control）。 技术上，通常如何进行并发控制？ 通过并发控制保证数据一致性的常见手段有： 锁（Locking） 数据多版本（Multi Versioning） 锁 如何使用普通锁保证一致性？ 操作数据前，锁住，实施互斥，不允许其他的并发任务操作； 操作完成后，释放锁，让其他任务执行； 如此这般，来保证一致性。 普通锁存在什么问题？ 简单的锁住太过粗暴，连“读任务”也无法并行，任务执行过程本质上是串行的。 于是出现了共享锁与排他锁： 共享锁（Share Locks，记为S锁），读取数据时加S锁 排他锁（eXclusive Locks，记为X锁），修改数据时加X锁 共享锁与排他锁的玩法是： 共享锁之间不互斥，简记为：读读可以并行

转自： https://www.cnblogs.com/rjzheng/p/10841031.html 作者：孤独烟 引言 照例，我们先来一个场景~ 面试官:"知道事务的四大特性么?" 你:"懂，ACID嘛，原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)！" 面试官:"你们是用mysql数据库吧，能简单说说innodb中怎么实现这四大特性的么？“ 你:"我只知道隔离性是怎么做的balabala~~" 面试官:"还是回去等通知吧~" OK，回到正题。说到事务的四大特性原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）、持久性（ Durability ），懂的人很多。但是稍微涉及细节一点，这四大特性在数据库中的实现原理是怎么样的？那就没有几个人能够答得上来了。因此，我们这篇文章着重讨论一下四大特性在Mysql中的实现原理。 正文 我们以从A账户转账50元到B账户为例进行说明一下ACID，四大特性。 原子性 根据定义，原子性是指一个事务是一个不可分割的工作单位，其中的操作要么都做，要么都不做。即要么转账成功，要么转账失败，是不存在中间的状态！ 如果无法保证原子性会怎么样？ OK，就会出现 数据不一致 的情形，A账户减去50元，而B账户增加50元操作失败

  1. 背景介绍   本文基于快递包裹取件(用户获取包裹并将包裹信息存储数据库)和包裹入库(快递员将包裹放入收发室并将包裹信息存储如数据库)场景，并将包裹入库信息和取件信息分别存入不同的数据库。这样当用户取件时，需要更新两个表信息(入库表中的包裹状态和取件表中插入取件信息)。   2. 问题描述   在采用 SSM 框架搭建后端服务时，若 Service 层业务逻辑较复杂，一条业务逻辑中可能会调用多个 dao 层更改数据库的接口。此时若采用 Spring 自带的 @Transactional 注解进行事务处理，将难以满足业务需求。正如代码块1所示： 代码块1 packet com.example.pickup; public interface PickUpDao{ @Delete("delete from pickup where orderNum=#{orderNum}") public int removePickUpPacket(String orderNum) } packet com.example.storage; public interface StorageDao{ @Update("update storage set isPickup=false where orderNum=#{orderNum}") public int

经常用到老搞混，从网上摘了点记录下来。 // 业务方法需要在一个事物中运行，如果方法运行时，已经存在一个事物中， // 那么加入该事物，否则为自己创建一个新事物。 @Transactional(propagation = Propagation.REQUIRED) public void test1() { } // 声明方法不需要事务，如果方法没有关联到一个事务，容器不会为它开启事物。 // 如果方法在一个事物中被调用，该事物会被挂起，在方法调用结束后，原先的 // 事物便会恢复执行。 @Transactional(propagation = Propagation.NOT_SUPPORTED) public void test2() { } // 表明不管是否存在事物，业务方法总会为自己发起一个新事物。 // 如果方法已经运行在一个事物中，则原有事物会被挂起， // 新的事物会被创建，直到方法执行结束，新事物才算结束， // 原先的事务才会被恢复执行。 @Transactional(propagation = Propagation.REQUIRES_NEW) public void test3() { } // 该属性指定业务方法只能在一个已经存在的事物中执行， // 业务方法不能发起自己的事物，如果业务方法在没有事物的环境 // 下调用，容器就会抛出异常。