Spring事务

事务的特性ACID：

一般来说，事务是必须满足4个条件（ACID）：：原子性（Atomicity，或称不可分割性）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。

• 原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

• 一致性：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。

• 隔离性：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。

• 持久性：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

概念说明

脏读（Dirty Reads）

        脏读，即一个事务读到了另一个事务还未提交的数据。如果脏读读取到的数据最终还是提交了倒还好，但如果这条数据最终回滚了，那么这条数据对于刚刚读取到它的事务而言，就是一条脏数据。

可重复读（Repeatable Reads）

        可重复读指的是在一个事务内，最开始读到的数据和事务结束前的任意时刻读到的同一批数据都是一致的。通常针对数据更新（UPDATE）操作。

不可重复读（Non-repeatable Reads）

        不可重复读，不同的事务读取同一条数据，读取到的内容是不同的。也就是说，对某一条数据而言，不同的事务以同样的重复操作读取，却产生了不同的结果。通常针对数据更新（UPDATE）操作。

幻读（Phantom Reads）

        幻读，一个事务按照某种查询条件，第一次读取的数据量和第二次读取的数据量不一样，就像幻觉一样，明明刚才查的是 N 条数据，再查一次就变成了 M 条（M <> N）。针对数据插入（INSERT）操作来说的。

事务隔离级别：

• Serializable：串行化。这是最严格的隔离级别，多个事务之间串行执行，资源消耗极大。
• Repeatable Read：可重复读。该级别可以确保一个已经被事务读取的数据，另一个事务不能修改这个数据，从而避免了 “脏读” 和 “不可重复读”。仍然有较大的性能损耗。MySQL默认隔离级别
• Read Commited：读已提交。这是大部分主流数据库默认的数据隔离级别。该级别下，只允许读已经提交的数据。例如：当一个事务修改了数据但未提交时，另一个并行事务只会读到该数据修改之前的内容，从而避免了 “脏读”。
• Read Uncommited：读未提交。一个事务可以读取另一个并行事务已修改但还未提交的数据。会产生 “脏读”。

Spring提供7 种事务传播行为

 

事务传播行为类型	说明
PROPAGATION_REQUIRED	如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是最常见的选择。
PROPAGATION_SUPPORTS	支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY	使用当前的事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW	新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED	以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER	以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED	如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作。

• PROPAGATION_REQUIRED，需要事务处理。有则使用，无则新建。这是 Spring 默认的事务传播行为。该级别的特性是，如果 Context 中已经存在事务，那么就将当前需要使用事务的代码加入到 Context 的事务中执行，如果当前 Context 中不存在事务，则新建一个事务执行代码。这个级别通常能满足大多数的业务场景。

• PROPAGATION_SUPPORTS，支持事务处理。该级别的特性是，如果 Context 存在事务，则将代码加入到 Context 的事务中执行，如果 Context 中没有事务，则使用 非事务 的方式执行。

• PROPAGATION_MANDATORY，强制性要求事务。该级别的特性是，当要以事务的方式执行代码时，要求 Context 中必须已经存在事务，否则就会抛出异常！使用 MANDATORY 强制事务，可以有效地控制 “必须以事务执行的代码，却忘记给它加上事务控制” 这种情况的发生。举个简单的例子：有一个方法，对这个方法的要求是一旦被调用，该方法就必须包含在事务中才能正常执行，那么这个方法就适合设置为 PROPAGATION_MANDATORY 强制事务传播行为，从而在代码层面加以控制。

• PROPAGATION_REQUIRES_NEW，每次都新建一个事务。该级别的特点是，当执行到一段需要事务的代码时，先判断 Context 中是否已经有事务存在，如果不存在，就新建一个事务；如果已经存在，就 suspend 挂起当前事务，然后创建一个新事务去执行，直到新事务执行完毕，才会恢复先前挂起的 Context 事务。

• PROPAGATION_NOT_SUPPORTED，不支持事务。该级别的特点是，如果发现当前 Context 中有事务存在，则挂起该事务，然后执行逻辑代码，执行完毕后，恢复先前挂起的 Context 事务。这个传播行为的事务，可以缩小事务处理过程的范围。举个简单例子，在一个事务中，需要调用一段非核心业务的逻辑操作 1000 次，如果将这段逻辑放在事务中，会导致该事务的范围变大、生命周期变长，为了避免因事务范围扩大、周期变长而引发一些的事先没有考虑到的异常情况发生，可以将这段逻辑设置为 NOT_SUPPORTED 不支持事务传播行为。

• PROPAGATION_NEVER，对事务要求更严格，不能出现事务！该级别的特点是，设置了该级别的代码，在执行前一旦发现 Context 中有事务存在，就会抛出 Runtime 异常，强制停止执行，有我无他！

• PROPAGATION_NESTED，嵌套事务。该级别的特点是，如果 Context 中存在事务 A，就将当前代码对应的事务 B 加入到 事务 A 内部，嵌套执行；如果 Context 中不存在事务，则新建事务执行代码。换句话说，事务 A 与事务 B 之间是父子关系，A 是父，B 是子。理解嵌套事务的关键点是：save point。

  父、子事务嵌套、save point 的说明：

  • 父事务会在子事务进入之前创建一个 save point；
  • 子事务 rollback ，父事务只会回滚到 save point，而不会回滚整个父事务；
  • 父事务 commit 之前，必须先 commit 子事务。