事务

1. 数据库引擎不支持事务 这里以 MySQL 为例，其 MyISAM 引擎是不支持事务操作的，InnoDB 才是支持事务的引擎，一般要支持事务都会使用 InnoDB。 根据 MySQL 的官方文档： https://dev.mysql.com/doc/refman/5.5/en/storage-engine-setting.html 从 MySQL 5.5.5 开始的默认存储引擎是：InnoDB，之前默认的都是：MyISAM，所以这点要值得注意，底层引擎不支持事务再怎么搞都是白搭。 2. 数据源没有配置事务管理器 @Bean public PlatformTransactionManager transactionManager(DataSource dataSource) { return new DataSourceTransactionManager(dataSource); } 如上面所示，当前数据源若没有配置事务管理器，那也是白搭！ 3. 没有被 Spring 管理 如下面例子所示： // @Service public class OrderServiceImpl implements OrderService { @Transactional public void updateOrder(Order order) { // update order } }

所有文章 https://www.cnblogs.com/lay2017/p/12078232.html 正文 在上一篇文章中，我们简单了解了一下innodb的 行级锁（s锁、x锁） 和 表级锁（is锁、ix锁） 的概念以及锁之间的兼容关系。 本文，将了解一下innodb的几种加锁的情况： 常见的加锁 1）对于 update、delete、insert 这种涉及到commit操作的语句，innodb自动会给相关的数据集加上 排它锁 （X锁）。 2）对于 普通的select语句 ，innodb 默认是不会加锁 的。但是，一个 事务中 我们可以 显示地 给select语句 加上共享锁（S锁）或者排它锁（X锁） 。这里注意，必须开启事务，在begin和commit/rollback之间才生效。 　　2-1）共享锁（S锁），例如：　　 select * from t_table where...lock in share mode 　　其它事务仍然可以查询记录，或者也加上share mode地共享锁，但不可以加互斥锁。同时要注意，如果当前事务加了共享锁，又准备对该数据进行更新操作（加排它锁），那么 可能就造成了死锁 。 　　2-2）排它锁（X锁），例如： select * from t_table where...for update 　　其它事务可以查询该记录

事务控制 spring中基于XML的声明式 配置事务管理器 配置事务的通知 tx:method isolation：用于指定事务的隔离级别，默认为DEFAULT，表示使用数据库的默认隔离级别。 propagation：用于指定事务的传播行为，默认值为REQUIRED，表示是一定会有事务，增删改查的选择。查询方法可以选择SUPPORTS read-only：用于指定事务是否只读，只有查询方法才能设置为true。默认值为false，表示读写 rollback-for：用于指定一个异常，当发生该异常时，事务回滚，产生其他异常时事务不回滚。没有默认值，表示任何异常都回滚 no-rollback-for：用于指定一个异常，事务不回滚，产生其他异常时事务回滚，没有默认值，表示任何异常都回滚 timeout：用于指定事务的超时时间，默认值为-1，表示永不超时。如果指定了该值，以秒为单位。 使用tx:advice标签配置事务通知 id：唯一标识 transaction-manager：事务管理器引用 配置aop通用切入点表达式 建立事务通知和切入点表达式的对应关系 示例 <!--配置连接池--> < bean id = " dataSource " class = " org.springframework.jdbc.datasource.DriverManagerDataSource " > <

这是在网上copy下来的ACID的概念，可以直接跳过看后面： 1、原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。 2、一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。 3、隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。 4、持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。 其中，原子性和持久性的概念比较好理解。但是最近发现老是把一致性和隔离性混淆。 个人理解，隔离性主要是针对读操作的。在不同事务之间，读操作隔离。比如另一个事务对数据修改后，会不会影响当前事务的读操作，要不要读到更新后的数据。 一致性，主要强调的是数据的更新是不是“正确”，即，是不是符合我们的预期，这个和读操作应该是要分开看待的，这里应该只强调写操作。 造成我对这俩个概念的混淆的原因是，在java的并发编程中，我们关注的似乎只有一致性

数据库启动： startup nomount ：创建并启动实例 startup mount ：创建实例并装载数据库 startup open ：创建实例、装载数据库、打开数据库(startup 默认为startup open) 数据库关闭： shutdown normal ：不允许新用户连接到数据库，不允许已连接用户启动新事务，回滚所有未提交的事务，所有已连接用户退出后再关闭数据库，下次启动无需恢复实例 shutdown transactional ：不允许新用户连接到数据库，不允许已连接用户启动新事务，等待用户回滚或提交未提交的事务后断开用户再关闭数据库，下次启动无需恢复实例 shutdown immediate ：不允许新用户连接到数据库，不允许已连接用户启动新事务，当前SQL语句立即中断，回滚所有未提交的事务后断开已连接用户再关闭数据库，下次启动无需恢复实例 shutdown abort ：中止所有正在运行的SQL语句，不回滚未提交的事务，不等待已连接用户退出就关闭数据库，下次启动需要恢复实例 后台进程 一、DBWR进程 数据库写进程（Data Base Writer），将高速缓冲区中的脏数据写入数据文件。 执行写操作： 1.数据缓存LRU列表长度等于脏缓冲区列表临界长度时，进行写操作 2.若查找LRU表时间过长且无可用缓冲区，则停止查找并进行写操作 3.出现超时（3s） 4

Spring transaction 什么是事务 A用户向B用户转帐100，第一步要从A帐户扣出100，第二步要将B帐户加上100。其中无论是第一步失败，还是第二步失败。都应该将A、B帐户的余额保持和转帐操作之前一致。 事务就是一系列相关联操作的集合，一个事务可以是多个步骤组成，如果一个步骤失败，那么整个流程都应该回滚到初始状态。 事务的四个特性 原子性（Atomicity） 一个事务是一个整体，无论有多少个步骤组成，要么所有步骤都成功，要么所有步骤都失败。 一致性（Consistency） 一个事务完成（无论是成功还是失败），所有的业务都应该处于一致的状态，不应该部分步骤成功，部分步骤失败，显示中的数据一致性不会被破坏。 隔离性（Isolation） 多个事务处理相同的数据的时候，事务间应该是相互隔离的，防止数据损坏。 持久性（Durability） 一旦事务完成，无论系统发生什么异常，结果都不应该受到影响，通常事务的结果被写入到数据库中。 Spring处理事务的核心接口 Spring涉及到事务管理的核心接口相互关系如下 Spring并没有直接提供事务管理的实现，而是提供了一个接口PlatformTransactionManager。具体的实现依赖项目中所使用的持久化接口。 PlatformTransactionManager 定义了所有的具体实现类必须要有的方法

Ream--(objc)写事务精简方案 地址: REALM-- Realm官方提供的的写事务有两种方式： A[realm beginWriteTransaction]; // ... [realm commitWriteTransaction]; B [realm transactionWithBlock:^{ //... }]; 由于realm强制线程安全，所以realm对象不适合持有。所以造成了realm写事务面向realm编程，而不是面向RLMObject编程。或者说realm的面向过的程痕迹还没消除干净,追求速度的realm由c++实现，realm选择了速度放弃了一些便利。 这种编码方式才是我们期望的[object commitTransaction:^(object){ object.key = value; }]; 常见的封装策略都是围绕AB两种形式。围绕A形式封装的问题是代码损耗大，作用域不直观，并且中间不能return，B形式封装的问题是夸闭包传值代码损耗大，调试原作用域浪费时间，不能return。 最理想的编码方式是一行 { @realm_writing; /// Begin commit object.key = value; } /// Commit when leava current scope. 这种编码方式需要借助析构函数，使用C++会要求所有

MySQL学习专栏 正在持续更新中：） 文章目录 DQL 数据查询语言 DDL 数据模式定义语言 DML 数据操作语言 DCL 数据控制语言 事务 Transaction MySQL语句众多，但有章可循，分类有助于学习 DQL 数据查询语言 DQL （data query language） query就是查询，类似question，query和JQery很像，也可以帮助记忆。 数据库语言中，查询是重点，很多优化算法和数据结构设计都是为了查询。 这里来做个实验： 我想查询大家的 工资 需要拿到一个表 名字-工资 的形式 该怎么办？ 确定数据库（data1） 总表在哪（employees） 需要的栏目是什么（名字，工资） 这里就要用到 select语句 。 USE data1; SELECT `first_name`, `last_name`, `salary` FROM employees; 明显 SELECT的是“栏目” FROM的是表格名称。 对表结构还不理解，或者，没有data1库，可以看我的上一个教程： 数据库学习之MySQL (三）——简单操作数据库 小试牛刀 然后data1数据库： data1.sql 数据库文件 配合阮菜鸡的MySQL教程使用 Q1 为啥每个栏目名字都加` 符号呢？ A1 设想，有个栏目叫show 系统会怎么识别？ 所以这个符号是为了

Fescar原理 1、概述 fescar刚推出不久，没几天。看了github的Issues，有人问：可以直接商用吗？ 作者的回复： image 我们也看一下fescard的历史： 阿里是国内最早一批进行应用分布式（微服务化）改造的企业，所以很早就遇到微服务架构下的分布式事务问题。 2014 年，阿里中间件团队发布 TXC（Taobao Transaction Constructor），为集团内应用提供分布式事务服务。 2016 年，TXC 经过产品化改造，以 GTS（Global Transaction Service） 的身份登陆阿里云，成为当时业界唯一一款云上分布式事务产品，在阿云里的公有云、专有云解决方案中，开始服务于众多外部客户。 2019 年起，基于 TXC 和 GTS 的技术积累，阿里中间件团队发起了开源项目 Fescar（Fast & EaSy Commit And Rollback, FESCAR），和社区一起建设这个分布式事务解决方案。 TXC/GTS/Fescar 一脉相承，为解决微服务架构下的分布式事务问题交出了一份与众不同的答卷。 阿里出品的中间件有一种精神是值得赞扬的，就是出品的任何中间件都是业务中已经使用多年的产品。都是经过锤炼的产品，开源的话，去除和内部业务耦合的代码，开源出来。至少有一点，底层的代码是经历过双11这种高并发请求量打磨过的代码

MVCC的实现原理 在InnoDB中，会在每行数据后添加两个额外的隐藏的值来实现MVCC，这两个值一个记录这行数据何时被创建，另外一个记录这行数据何时过期（或者被删除）。 在实际操作中，存储的并不是时间，而是事务的版本号，每开启一个新事务，事务的版本号就会递增。 在可重读Repeatable reads事务隔离级别下： SELECT时，读取创建版本号<=当前事务版本号，删除版本号为空或>当前事务版本号。 INSERT时，保存当前事务版本号为行的创建版本号 DELETE时，保存当前事务版本号为行的删除版本号 UPDATE时，插入一条新纪录，保存当前事务版本号为行创建版本号，同时保存当前事务版本号到原来删除 MVCC是基于乐观锁实现的方法，并且可以解决部分幻读问题，因为减少了锁的使用，提高了性能，仅锁住了必要的行 只能在RC与RR隔离级别中实现 MySql的四种隔离级别 SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。 Read Uncommitted（读取未提交内容） 在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。 Read