Spring事务管理

一、Spring 事务管理的两种方式
1️⃣编程式事务侵入到了业务代码里面，但是提供了更加详细的事务管理。编程式事务使用 TransactionTemplate 或者直接使用底层的 PlatformTransactionManager。对于编程式事务管理，Spring 推荐使用 TransactionTemplate。
2️⃣声明式事务基于AOP，既能管理事务，又不影响业务代码。本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在目标方法执行完后根据执行情况提交或者回滚事务。最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明(或基于@Transactional的方式)，便可以将事务规则应用到业务逻辑中。

二、对比说明
显然声明式事务管理要优于编程式事务管理，这正是 Spring 倡导的非侵入式的开发方式。声明式事务管理使业务代码不受污染，一个POJO，只要加上注解就可以获得完全的事务支持。和编程式事务相比，声明式事务唯一不足的地方，它的最细粒度只能作用到方法级别，无法做到像编程式事务那样可以作用到代码块级别。但是即便有这样的需求，也存在很多变通的方法，比如，可以将需要进行事务管理的代码块独立为方法等等。

三、声明式事务管理的两种实现
声明式事务管理有两种常用的方式，一种是基于 tx 和 aop 名字空间的 xml 配置文件，另一种就是基于 @Transactional。显然基于注解的方式更简单易用，更清爽。

四、@Transactional 一般可以作用在类或者方法上
1️⃣作用于类：当把 @Transactional 放在类上时，表示该类所有的 public 方法都配置相同的事务属性信息。
2️⃣作用于方法：当类配置了@Transactional，方法也配置了 @Transactional，方法的事务会覆盖类的事务配置信息。

五、Spring 事务的基本原理
Spring 事务的本质其实就是数据库对事务的支持，没有数据库的事务支持，Spring 是无法提供事务功能的。对于纯 JDBC 操作数据库，想要用到事务，可以按照以下步骤进行：

获取连接 Connection con = DriverManager.getConnection()；
开启事务 con.setAutoCommit(true/false)；
执行 CRUD；
提交事务/回滚事务 con.commit()/con.rollback()；
关闭连接 con.close()。

使用 Spring 的事务管理功能后，开发者可以不再写步骤 2 和 4 的代码，而是由 Spirng 自动完成。Spring 是如何在 CRUD 前后开启/关闭事务的？解决这个问题，也就可以从整体上理解 Spring 的事务管理实现原理了。下面简单地介绍下，注解方式为例子：

配置文件开启注解驱动，在相关的类和方法上通过 @Transactional 标识。
Spring 在启动的时候会去解析生成相关的 bean，这时候会查看拥有相关注解的类和方法，并且为这些类和方法生成代理，并根据 @Transactional 的相关参数进行相关配置注入，这样就在代理中把相关的事务实现了(开启正常提交事务，异常回滚事务)。
真正的数据库层的事务提交和回滚是通过redo log/binlog实现的。
六、原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)
事务最经典的例子就是转账了。假如小黑要给小白转账 100 元，这个转账会涉及到两个关键操作就是：将小黑的余额减少 100 元，将小白的余额增加 100 元。万一在这两个操作之间突然出现错误(如银行系统崩溃等)，导致小黑余额减少而小白的余额没有增加，这样就不对了。事务就是保证这两个关键操作要么都成功，要么都要失败。

1️⃣原子性。一个事务是一个不可分割的工作单位，事务中包括的操作要么都做，要么都不做。
2️⃣一致性。事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。
3️⃣隔离性。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
4️⃣持久性。持久性也称永久性(permanence)，指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

七、简述事务是恢复和并发控制的基本单位。
事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。事务通常由高级数据库操纵语言或编程语言(如 SQL、C++ 或 Java)书写的用户程序的执行所引起，并用形如 begin transaction 和 end transaction 语句(或函数调用)来界定。事务由事务开始(begin transaction)和事务结束(end transaction)之间执行的全体操作组成。例如：在关系数据库中，一个事务可以是一条 SQL 语句，一组 SQL 语句或整个程序。

事务隔离级别定义了在一个事务中，哪些数据是对当前执行的语句“可见”的。在并发访问数据库时，事务隔离级别定义了多个事务之间对于同个目标数据源访问时的可交叉程度。

八：可交叉事务

1️⃣Dirty Read(脏读) 看到的数据则是不正确的

当一个事务能看见另外一个事务未提交的数据时，就称为脏读。如果这个事务被回滚而不是提交了，那么其它事务看到的数据则是不正确的，是“脏”的。

 

 

2️⃣Non-repeatable Read(不可重复读) 两次读取到的数据不同

假设事务 A 读取了一行数据，接下来事务 B 改变了这行数据，之后事务 A 再一次读取该行数据，结果就是事务 A 两次读取到的数据不同。

 

3️⃣Phantom Read(幻读) 发现多出来一条数据

假设事务 A 通过一个 where 条件读取到了一个结果集，此时事务 B 插入了一条符合事务 A 的 where 条件的数据，之后事务 A 再次执行同样的查询时，发现多出来一条数据。

 

三、事务隔离级别(Isolation)
JDBC 规范增加了隔离级别，来满足了 SQL:2003 定义的 4 种事务隔离级别。在安装MySQL时，安装默认的隔离级别就是：可重复读。可以通过 select @@global.tx_isolation; 来查看当前隔离级别。隔离级别从最宽松到最严格，排序如下所示：

1️⃣TRANSACTION_NONE
这意味着当前的 JDBC 驱动不支持事务，也意味着这个驱动不符合 JDBC 规范。

2️⃣READ_UNCOMMITTED(读未提交)
允许事务看到其它事务修改了但未提交的数据，这意味着有可能是脏读、不可重复读或者幻读。

3️⃣READ_COMMITTED(读提交)
一个事务在未提交之前，所做的修改不会被其它事务所看见。这能避免脏读，但避免不了不可重复读和幻读。

4️⃣REPEATABLE_READ(可重复读取) MySQL默认的事务隔离级别
避免了脏读和不可重复读，但幻读依然是有可能发生的。

5️⃣SERIALIZABLE(序列化)
避免了脏读、不可重复读以及幻读。

四、Propagation：用来枚举事务的传播行为
所谓事务的传播行为就是多个事务方法相互调用时，事务如何在这些方法间传播。Spring 支持 7 种事务传播行为，默认为 REQUIRED。

1️⃣REQUIRED
@Transactional(propagation=Propagation.REQUIRED)
如果当前有事务，加入到这个事务中。如果当前没有事务，就新建一个事务。

2️⃣REQUIRES_NEW
@Transactional(propagation=Propagation.REQUIRES_NEW)
不管是否存在事务，都创建一个新的事务，原来的挂起，新的执行完毕，继续执行老的事务。表示当前方法必须运行在它自己的事务中。如果使用 JTATransactionManager 的话，则需要访问 TransactionManager。

3️⃣MANDATORY
@Transactional(propagation=Propagation.MANDATORY)
表示该方法必须在事务中运行，如果当前不存在事务，则会抛出一个异常。不会主动开启一个事务。

4️⃣NEVER
@Transactional(propagation=Propagation.NEVER)
表示该方法不应该运行在事务上下文中，如果当前正有一个事务在运行，则会抛出异常。(与Propagation.MANDATORY相反)。

5️⃣SUPPORTS
@Transactional(propagation=Propagation.SUPPORTS)
表示当前方法不需要事务上下文，但是如果存在当前事务的话，那么这个方法会在这个事务中运行。

6️⃣NOT_SUPPORTED
@Transactional(propagation=Propagation.NOT_SUPPORTED)
表示该方法不应该运行在事务中，如果存在当前事务，在该方法运行期间，当前事务将被挂起。如果使用 JTATransactionManager 的话，则需要访问 TransactionManager。

7️⃣NESTED
@Transactional(propagation=Propagation.NESTED)
表示如果当前已经存在事务，那么该方法将会在嵌套事务中运行。嵌套的事务可以独立于当前事务进行单独地提交或回滚。如果当前不存在事务，那么其行为等价于 Propagation.REQUIRED。嵌套事务一个非常重要的概念就是内层事务依赖于外层事务。外层事务失败时，会回滚内层事务所做的动作。而内层事务操作失败并不会引起外层事务的回滚。

综上所述，NESTED 和 REQUIRES_NEW 非常相似，都是开启一个属于它自己的新事务。使用 REQUIRES_NEW 时，内层事务与外层事务就像两个独立的事务一样，一旦内层事务进行了提交后，外层事务不能对其进行回滚。当内部事务开始执行时, 外部事务将被挂起，内务事务结束时，外部事务将继续执行。两个事务互不影响，两个事务不是一个真正的嵌套事务，同时它还需要 JTA 事务管理器的支持。

使用 NESTED 时，外层事务的回滚可以引起内层事务的回滚，而内层事务的异常并不会导致外层事务的回滚，它是一个真正的嵌套事务。嵌套事务开始执行时，它将取得一个 savepoint，如果这个嵌套事务失败，将回滚到此 savepoint。嵌套事务是外部事务的一部分，只有外部事务结束后它才会被提交。