Transaction 那点事儿

转载自黄勇的博客，Java那点事儿系列

事务的四个特性

原子性（Atomicity）：事务必须是一个不可分割的整体，要么做完，要么就不做。

一致性（Consistency）：也就是说，执行完数据库操作后，数据不会被破坏。打个比方，如果从 A 账户转账到 B 账户，不可能因为 A 账户扣了钱，而 B 账户没有加钱吧。

隔离性（Isolation）：当我们编写了一条 update 语句，提交到数据库的一刹那间，有可能别人也提交了一条 delete 语句到数据库中。也许我们都是对同一条记录进行操作，我们必须保证数据库操作之间是“隔离”的，我们要制定一个规范，让各个数据库厂商都支持我们的规范：事务隔离级别（Transaction Isolation Level）

READ_UNCOMMITTED
READ_COMMITTED
REPEATABLE_READ
SERIALIZABLE

从上往下，级别越来越高，并发性越来越差，安全性越来越高，反之则反。

持久性（Durability）：当我们执行一条 insert 语句后，数据库必须要保证有一条数据永久地存放在磁盘中，这个也算事务的一条特性。

事务的隔离级别

其实最难理解的反倒不是一致性，而是隔离性。因为它是保证一致性的重要手段，是工具，使用它不能有半点差池，否则后果自负！其实，定义这四个级别就是为了解决数据在高并发下所产生的问题，那又有哪些问题呢？

Dirty Read（脏读）
Unrepeatable Read（不可重复读）
Phantom Read（幻读）

脏读


时间	事务 A（存款）	事务 B（取款）
T1	开始事务
T2		开始事务
T3		查询余额（1000 元）
T4		取出 1000 元（余额 0 元）
T5	查询余额（0 元）
T6		撤销事务（余额恢复为 1000 元）
T7	存入 500 元（余额 500 元）
T8	提交事务

余额应该为 1500 元才对！请看 T5 时间点，事务 A 此时查询余额为 0 元，这个数据就是脏数据，它是事务 B 造成的，明显事务没有进行隔离，渗过来了，乱套了。

所以脏读这件事情是非常要不得的，一定要解决掉！

不可重复读

事务 A 其实除了查询了两次以外，其他什么事情都没有做，结果钱就从 1000 变成 0 了，这就是重复读了。可想而知，这是别人干的，不是我干的。其实这样也是合理的，毕竟事务 B 提交了事务，数据库将结果进行了持久化，所以事务 A 再次读取自然就发生了变化。

这种现象基本上是可以理解的，但在有些变态的场景下却是不允许的。

幻读

银行工作人员，每次统计总存款，都看到不一样的结果。不过这也确实也挺正常的，总存款增多了，肯定是这个时候有人在存钱。但是如果银行系统真的这样设计，那算是玩完了。这同样也是事务没有隔离所造成的。

归纳一下，以上提到了事务并发所引起的跟读取数据有关的问题，各用一句话来描述一下：

脏读：事务 A 读取了事务 B 未提交的数据，并在这个基础上又做了其他操作。
不可重复读：事务 A 读取了事务 B 已提交的更改数据。
幻读：事务 A 读取了事务 B 已提交的新增数据。

第一条是坚决抵制的，后两条在大多数情况下可不作考虑。

事务隔离级别	脏读	不可重复读	幻读
READ_UNCOMMITTED	允许	允许	允许
READ_COMMITTED	禁止	允许	允许
REPEATABLE_READ	禁止	禁止	允许
SERIALIZABLE	禁止	禁止	禁止

Spring 事务传播行为

Spring 的解决方案吧，其实它是对 JDBC 的一个补充或扩展。它提供了一个非常重要的功能，就是：事务传播行为（Transaction Propagation Behavior）。

PROPAGATION_REQUIRED
RROPAGATION_REQUIRES_NEW
PROPAGATION_NESTED
PROPAGATION_SUPPORTS
PROPAGATION_NOT_SUPPORTED
PROPAGATION_NEVER
PROPAGATION_MANDATORY

首先要明确的是，事务是从哪里来？传播到哪里去？答案是，从方法 A 传播到方法 B。Spring 解决的只是方法之间的事务传播，那情况就多了，比如：

方法 A 有事务，方法 B 也有事务。
方法 A 有事务，方法 B 没有事务。
方法 A 没有事务，方法 B 有事务。
方法 A 没有事务，方法 B 也没有事务

假设事务从方法 A 传播到方法 B，您需要面对方法 B，问自己一个问题：

方法 A 有事务吗？

如果没有，就新建一个事务；如果有，就加入当前事务。这就是 PROPAGATION_REQUIRED，它也是 Spring 提供的默认事务传播行为，适合绝大多数情况。
如果没有，就新建一个事务；如果有，就将当前事务挂起。这就是 RROPAGATION_REQUIRES_NEW，意思就是创建了一个新事务，它和原来的事务没有任何关系了。
如果没有，就新建一个事务；如果有，就在当前事务中嵌套其他事务。这就是 PROPAGATION_NESTED，也就是传说中的“嵌套事务”了，所嵌套的子事务与主事务之间是有关联的（当主事务提交或回滚，子事务也会提交或回滚）。
如果没有，就以非事务方式执行；如果有，就使用当前事务。这就是 PROPAGATION_SUPPORTS，这种方式非常随意，没有就没有，有就有，有点无所谓的态度，反正我是支持你的。
如果没有，就以非事务方式执行；如果有，就将当前事务挂起。这就是 PROPAGATION_NOT_SUPPORTED，这种方式非常强硬，没有就没有，有我也不支持你，把你挂起来，不鸟你。
如果没有，就以非事务方式执行；如果有，就抛出异常。这就是 PROPAGATION_NEVER，这种方式更猛，没有就没有，有了反而报错，确实够牛的，它说：我从不支持事务！
如果没有，就抛出异常；如果有，就使用当前事务。这就是 PROPAGATION_MANDATORY，这种方式可以说是牛逼中的牛逼了，没有事务直接就报错，确实够狠的，它说：我必须要有事务！

Spring 给我们带来了事务传播行为，这确实是一个非常强大而又实用的功能。除此以外，也提供了一些小的附加功能，比如：

事务超时（Transaction Timeout）：为了解决事务时间太长，消耗太多的资源，所以故意给事务设置一个最大时常，如果超过了，就回滚事务。
只读事务（Readonly Transaction）：为了忽略那些不需要事务的方法，比如读取数据，这样可以有效地提高一些性能。

Spring配置

<tx:annotation-driven />
  
@Transactional
public void xxx() {
    ...
}

可在 @Transactional 注解中设置：事务隔离级别、事务传播行为、事务超时时间、是否只读事务。

思维导图

参考：