注意:spring中的事务是本地事务,是在同一个Mysql的同一个库中发生的事情,一般配置在service层,底层是AOP原理
理解:事务是逻辑上的一组操作,
要么什么都不做,要么什么都做
文明系统的每个业务方法可能包括了多个原子性的数据库操作,比如下面的savePerson()方法中就有两个原子性的数据库操作。这些原子性的数据库操作是有依赖的,他们要么都执行,要么都不执行
public void savePerson() {
personDao.save(person);
personDetailDao.save(personDetail);
}
注意:
- 事务能否生效主要看数据库引擎是否支持事务。
- 例如:mysql数据库默认使用支持事务的innodb引擎,但是如果把innodb引擎变为myisam,那么引擎也就不再支持事务了
转账业务:假设小明要给小红转账1000元,这个转账会涉及到两个关键的操作就是:
1.将小明的余额减少1000
2.将小红的余额增加1000
万一在这两个操作之间突然出现错误比如银行系统崩溃或者网络故障,导致小明余额减少而小红余额没有增加,就会出现错误对吧,而事务在这种情况下会做什么?
事务就是保证这两个关键的操作要么都成功,要么都失败
public class OrdersService {
private AccountDao accountDao;
public void setOrdersDao(AccountDao accountDao) {
this.accountDao = accountDao;
}
@Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.DEFAULT, readOnly = false, timeout = -1)
public void accountMoney() {
//小红账户多1000
accountDao.addMoney(1000, xiaohong);
//模拟突然出现的异常,比如银行中可能为突然停电等等
// 如果没有配置事务管理的话会造成,小红账户多了1000而小明账户没有少钱
int i = 10 / 0;
// 小王账户少1000
accountDao.reduceMoney(1000, xiaoming);
}
}
}
**原子性(**Atomicity): 一个事务(transaction)中的所有操作,或者全部完成,或者全部不完成font>,事务在执行过程中发生错误,会被回滚(Rollback)
**一致性(****Consistency):数据库的完整性没有被破坏。这表 示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。
持久性(Durability)数据的修改就是永久的,数据修改写入到磁盘。
****隔离性(******Isolation):数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可 以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别,包括
未提交读(Readuncommitted)、
提交读(read committed)、
可重复读(repeatable read)和
串行化(Serializable)。
注意:
1.保证了原子性就保证了一致性
我们知道如果想要保证事务的原子性,就需要在异常发生时,对已经执行的操作进行回滚,在
MySQL 中,恢复机制是通过 回滚日志(undo log) 实现的,所有事务进行的修改都会先先记录
到这个回滚日志中,然后再执行相关的操作。如果执行过程中遇到异常的话,我们直接利用 回滚
日志 中的信息将数据回滚到修改之前的样子即可!并且,回滚日志会先于数据持久化到磁盘上。
这样就保证了即使遇到数据库突然宕机等情况,当用户再次启动数据库的时候,数据库还能够通
过查询回滚日志来回滚将之前未完成的事务。
基本概念
- 脏读: 读取了别的事务还没提交的数据
- 幻读: 使用相同的 SQL 两次读取,第二次读取到其他事务新插入的行(注重于数据的修改)
- 不可重复读:多次读取同一个数据时,结果出现不一致(注重于数据的插入)
隔离级别 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|
未提交读:READ UNCOMMITTED | 有 | 有 | 有 |
提交读:READ COMMITTED | 无 | 有 | 有 |
可重复读(默认):REPEATABLE READ | 无 | 无 | 有 |
序列化:SERIALIZABLE | 无 | 无 | 无 |
我们对于ACID主要研究探讨隔离性,Mysql中事务的隔离级别为四种
- SERIALIZABLE 序列化
- REPEATABLE READ 重复读取
- READ COMMITTED 提交读
- READ UNCOMMITTED 未提交读
- 事务不可以并发执行
- 一次只能执行一个事务
- 隔离级别最高,所以它不存在任何问题
- 但是因为它的效率比较低,所以一般不用它
- MySQL 数据库中的默认事务隔离级别
- 理解:指在同一个事务内,多次读取同一个数据
- 事务不会被看成一个序列,但是正在执行事务的变化仍然不能被外部看到。
- 例子:如果用户在当前事务对数据进行了更改,然后执行
SELECT
语句(显然此时查询的是更改之后的数据),同时在另一个事务中执行了同一条SELECT
语句多次,结果总是与更改之前的数据是相同的- 这个隔离级别中解决了事务的不可重复读
- 幻读问题没有解决
- 可以看到其他事务对数据的修改
- 即,在事务处理期间,如果其他事务修改了相应的表,那么同一个事务的多个
SELECT
语句可能返回不同的结果- 存在两种问题:不可重复读和幻读
- 事务之间最小限度的隔离,在这种隔离级别中,可以读到别的事务未提交的数据
- 存在三种问题:脏读、不可重复读、幻读
以上四种从上往下
1.效率越来越高
2.隔离级别越来越低,安全性越来越低
SELECT @@GLOBAL.tx_isolation, @@tx_isolation;
- @@GLOBAL意思全局的
- 查询全局隔离级别:@@GLOBAL.tx_isolation
- 查询会话隔离级别:@@tx_isolation
可以看到,默认的隔离级别为 REPEATABLE-READ,全局隔离级别和当前会话隔离级别皆是如此
就是关键字变了,其他都一样。
SELECT @@GLOBAL.transaction_isolation, @@transaction_isolation;
通过如下命令可以修改隔离级别(建议开发者在修改时修改当前 session 隔离级别即可,不用修改全局 的隔离级别)
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
上面这条 SQL 表示将当前 session 的数据库隔离级别设置为 READ UNCOMMITTED,设置成功后,再
次查询隔离级别,发现当前 session 的隔离级别已经变了,如图1-2:
注意,如果只是修改了当前 session 的隔离级别,则换一个 session 之后,隔离级别又会恢复到默认
的隔离级别,所以我们测试时,修改当前 session 的隔离级别即可。
注意,如果读者使用的是 Navicat 的话,不同的查询窗口就对应了不同的 session**,如果读者使用了SQLyog的话,不同查询窗口对应同一个 session**,因此如果使用** SQLyog**,需要读者再开启一个新的** 连接,在新的连接中进行查询操作。
含义:一个事务读取到另外一个事务还没有提交的数据,称之为脏读。
START TRANSACTION;
UPDATE account set balance=balance+100 where name='huang';
UPDATE account set
balance=balance-100 where name='hei';
COMMIT;
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
START TRANSACTION;
SELECT * from account;
COMMIT;
可以看到,A 窗口中的事务,虽然还未提交,但是 B 窗口中已经可以查询到数据的相关变化了。
这就是脏读问题。
概念:不可重复读是指一个事务先后读取同一条记录,但两次读取的数据不同,称之为不可重复读。
START TRANSACTION;
SELECT * from account where name='huang';
COMMIT;
START TRANSACTION;
UPDATE account set balance=balance+100 where name='huang';
COMMIT;
huang的账户已经发生了变化,即前后两次查看 huang账户,结果不一致,这就是不可重复读。
和脏读的区别在于,脏读是看到了其他事务未提交的数据,而不可重复读是看到了其他事务已经提交的
数据(由于当前 SQL 也是在事务中,因此有可能并不想看到其他事务已经提交的数据)。
START TRANSACTION;
insert into account(name,balance) values('zhangsan',1000);
COMMIT;
START TRANSACTION;
SELECT * from account; delete from account where name='zhangsan';
COMMIT;
首先执行 B 窗口的前两行,开启一个事务,同时查询数据库中的数据,此时查询到的数据只有
huang和 hei。
执行 A 窗口的前两行,向数据库中添加一个名为 zhangsan 的用户,注意不用提交事务。
执行 B 窗口的第二行,由于脏读问题,此时可以查询到 zhangsan 这个用户。
执行 B 窗口的第三行,去删除 name 为 zhangsan 的记录,这个时候删除就会出问题,虽然在 B
窗口中可以查询到 zhangsan,但是这条记录还没有提交,是因为脏读的原因才看到了,所以是没
法删除的。此时就产生了幻觉,明明有个 zhangsan,却无法删除。
这就是幻读。
和 READ UNCOMMITTED 相比,READ COMMITTED 主要解决了脏读的问题,对于不可重复读和幻象 读则未解决。
将事务的隔离级别改为 READ COMMITTED 之后,重复上面关于脏读案例的测试,发现已经不存在脏读 问题了;
重复上面关于不可重复读案例的测试,发现不可重复读问题依然存在。
上面那个案例不适用于幻读的测试,我们换一个幻读的测试案例
第一步:将 B 窗口的隔离级别改为 READ COMMITTED
第二步 A窗口 测试 SQL:
START TRANSACTION;
insert into account(name,balance) values('zhangsan',1000);
COMMIT;
第三步 B窗口测试SQL :
START TRANSACTION; SELECT * from account;
insert into account(name,balance) values('zhangsan',1000);
COMMIT;
- 测试方式如下:
- 首先执行 B 窗口的前两行 SQL,开启事务并查询数据,此时查到的只有 huang和 hei两个用户。
- 执行 A 窗口的前两行 SQL,插入一条记录,但是并不提交事务。
- 执行 B 窗口的第二行 SQL,由于现在已经没有了脏读问题,所以此时查不到 A 窗口中添加的数 据。
- 执行 B 窗口的第三行 SQL,由于 name 字段唯一,因此这里会无法插入。此时就产生幻觉了,明 明没有 zhangsan 这个用户,却无法插入 zhangsan
和 READ COMMITTED 相比,REPEATABLE READ 进一步解决了不可重复读的问题,但是幻象读则未解决
REPEATABLE READ 中关于幻读的测试和上一小节基本一致,不同的是第二步中执行完插入 SQL 后记得
提交事务。
由于 REPEATABLE READ 已经解决了不可重复读,因此第二步即使提交了事务,第三步也查不到已经提
交的数据,第四步继续插入就会出错。
**注意,**REPEATABLE READ 也是 InnoDB 引擎的默认数据库事务隔离级别
SERIALIZABLE 提供了事务之间最大限度的隔离,在这种隔离级别中,事务一个接一个顺序的执行,不
会发生脏读、不可重复读以及幻象读问题,最安全。
如果设置当前事务隔离级别为 SERIALIZABLE,那么此时开启其他事务时,就会阻塞,必须等当前事务
提交了,其他事务才能开启成功,因此前面的脏读、不可重复读以及幻象读问题这里都不会发生。
隔离级别 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|
未提交读:READ UNCOMMITTED | 有 | 有 | 有 |
提交读:READ COMMITTED | 无 | 有 | 有 |
可重复读(默认):REPEATABLE READ | 无 | 无 | 有 |
序列化:SERIALIZABLE | 无 | 无 | 无 |
可重复读以及幻象读问题,最安全。
如果设置当前事务隔离级别为 SERIALIZABLE,那么此时开启其他事务时,就会阻塞,必须等当前事务
提交了,其他事务才能开启成功,因此前面的脏读、不可重复读以及幻象读问题这里都不会发生。