24Spring_事务管理机制

第一部分：Spring事务管理高层抽象接口

我们介绍三个接口：1.PlatformTransactionManager 2.TransactionDefinition  3.TransactionStatus

PlatformTransactionManager 平台事务管理器

使用Spring管理事务，需要为不同持久层技术实现，提供不同事务管理器（实现类）。下面给一个PlatformTransactionManager的实现类的表。

这个表格的左侧的事务都是PlatformTransactionManager的实现类。右侧的说明都是他们具体的功能。

DataSourceTransactionManager是对Jdbc、ApacheDbUtils、JdbcTemplate、MyBatis 进行事务管理的类。

HibernateTransactionManager是对Hibernate 进行事务管理得类。

我们先来了解PlatformTransactionManager这个接口。

PlatformTransactionManager这个接口有以下3个方法：

1.commit 提交事务

2.rollback 回滚事务

3.TransactionStatus getTransaction(TransactionDefinition) 根据事务定义信息获取事务状态信息。

我们来看一下TransactionDefinition这个接口。TransactionDefinition这个接口是事务定义信息（Spring对事务管理 配置信息）

这个接口主要有以下静态变量和方法：

下面的Method Summary都是针对上面的Field Summary设置的。这些方法也都是为了得到Fileld Summary的。

针对Field Summary我们分为以下4类：

1.以ISOLATION开头的 ISOLATION_* ：事务隔离级别

扩展阅读：

什么是事务隔离：

事务是指对系统进行的一组操作，为了保证系统的完整性，事务需要具有ACID特性，1. 原子性（Atomic），2. 一致性（Consistency）3. 隔离性（Isolation）4. 持久性（Durability）。

其中的隔离性具体解释如下：

隔离性（Isolation）
     并发事务之间互相影响的程度，比如一个事务会不会读取到另一个未提交的事务修改的数据。在事务并发操作时，可能出现的问题有：
     脏读：事务A修改了一个数据，但未提交，事务B读到了事务A未提交的更新结果，如果事务A提交失败，事务B读到的就是脏数据。
     不可重复读：在同一个事务中，对于同一份数据读取到的结果不一致。比如，事务B在事务A提交前读到的结果，和提交后读到的结果可能不同。不可重复读出现的原因就是事务并发修改记录，要避免这种情况，最简单的方法就是对要修改的记录加锁，这回导致锁竞争加剧，影响性能。另一种方法是通过MVCC可以在无锁的情况下，避免不可重复读。
     幻读：在同一个事务中，同一个查询多次返回的结果不一致。事务A新增了一条记录，事务B在事务A提交前后各执行了一次查询操作，发现后一次比前一次多了一条记录。幻读是由于并发事务增加记录导致的，这个不能像不可重复读通过记录加锁解决，因为对于新增的记录根本无法加锁。需要将事务串行化，才能避免幻读。
     事务的隔离级别从低到高有：
     Read Uncommitted：最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。
     Read Committed：只有在事务提交后，其更新结果才会被其他事务看见。可以解决脏读问题。
     Repeated Read：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。
     Serialization：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。
     通常，在工程实践中，为了性能的考虑会对隔离性进行折中。

就是说：事务特性（ACID 原子性、一致性、隔离性、持久性 ） ，事务隔离性引发问题（脏读、不可重复读、 虚读 ）， 数据库为了解决事务隔离性导致问题，引入四个隔离级别。

2.PROPAGATION_* 事务的传播行为

传播行为不是数据库特性， 那为什么Spring提到它了呢？主要是解决企业实际开发中事务隔离问题 ---- 解决两个事务互相调用的问题。Spring 是为了解决企业的问题开发的。

下面解释一下什么是两个事务互相调用的问题：

解释一下上面的两个例子：

案例1：我去取钱，在业务层里面执行取钱的操作，执行一个事务：{public xxx取钱（）,打印凭条（）}，这个事务执行时，可能xxx取钱这个方法执行了，但是打印凭条这个方法执行失败了，那么这个事务是执行呢还是回滚呢？当然不能回滚，如果回滚的话，钱都给你了，但是银行那边钱没有减少。这怎么可能。所以这两个方法不能在同一个事务中。

案例2:商城删除用户的案例，在一个业务里面执行删除用户的方法和删除订单的方法。如果删除用户这个方法执行了，但是删除订单这个方法没有执行。那可能要事务回滚啊。所以这两个方法应该在同一个事务中。

所以事务传播行为就是为了解决一些方法要不要执行同一个事务（案例2），还是重新开启一个事务（案例1）的问题。

下面给出Spring提供的7种事务传播行为类型：

REQUIRED ： 比如说删除用户，删除订单。 将使用同一个事务 ，删除订单必须存在事务

SUPPRTS ：删除用户，删除订单， 如果删除用户的时候有事务，那么删除订单的时候使用事务，如果删除用户的没有事务。那么删除订单的时候就不用事务

MANDATORY：删除用户，删除订单， 使用同一个事务，如果删除用户没有事务，删除订单直接抛出异常。

REQUIRES_NEW： ATM取款方法后，打印凭条方法必须开启一个新的事务

NOT_SUPPORT：ATM取款后，打印凭条不使用事务运行

NEVER ： 如果ATM取款，开启事务，打印凭条直接抛出异常

NESTED ： 嵌套事务 （只对DataSourceTransactionManager 起效）， ATM取款和打印凭条处于同一个事务，在ATM取款后，设置SavePoint保存点（jdbc的知识），如果打印凭条出现问题，可以回滚到保存点。那就是说即使我的打印凭条方法出问题了也就是回滚到Atm取款的时候，并没有回滚到最原始的地方，这样对银行也没有损失啊。

重点学习： REQUIRED、REQUIRES_NEW、NESTED

要想明白这三个是不是同一个事务？

REQUIRED在同一个事务。

REQUIRES_NEW不在同一个事务。

NESTED在同一个事务。

3.TIMEOUT_DEFAULT 超时时间

4.Read-Only 是否只读 （如果只读事务，不能执行 insert、update、delete操作）

最后介绍一下TransactionStatus 这个接口。这个接口是事务状态信息（事务在执行过程中，某一个时间点状态）

这三个接口是Spring事务管理最核心的三个接口。