【Spring】事务的实现方式
原文链接：https://tidyko.com/posts/c87c55c4.html
1 初步理解
理解事务之前，先讲一个你日常生活中最常干的事：转账。
场景设定：
用户名 余额
A 1000
B 1000
操作：
A通过支付宝给B转账200块，做这件事情会进行两个操作。
1：A账号-200
2：B账号+200
结果：
1：所以如果成功进行了一次转账操作的话，得到的数据应该是如下：
用户名 余额
A 800
B 1200
2：但是如果是在失败的情况下，没有做事务处理的话，可能会得到一种情况就是：
用户名 余额
A 800
B 1000
从上面的数据看，A账号成功扣除了200之后，由于某些不可预测的原因，中断了交易，这时候从A账号扣除的200块并未成功加入到B账号当中。
总结：
从上面的失败案例看我们理想的情况是，如果转账失败的情况下应该是A账号没有扣除200块，同时B账号也不会增加200块，即以下所示：
用户名 余额
A 1000
B 1000
所以，这里我们提出了一个概念：事务。
事务就是用来解决类似问题的。事务是一系列的动作，它们综合在一起才是一个完整的工作单元，这些动作必须全部完成，如果有一个失败的话，那么事务就会回滚到 最开始的状态，仿佛什么都没发生过一样。
在企业级应用程序开发中，事务管理必不可少的技术，用来确保数据的完整性和一致性。
事务有四个特性：ACID
-
-
- 原子性（Atomicity）：事务是一个原子操作，由一系列动作组成。事务的原子性确保动作要么全部完成，要么完全不起作用。
- 一致性（Consistency）：不管操作是成功还是失败，事务必须保持数据前后的一致性，比如A给B转账，两个人的总金额合计2000块，转账前与转账后，两人的总金额合计都必须是2000块。
- 隔离性（Isolation）：可能有许多事务会同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏，避免出现脏读，幻读，不可重复读的状况。比如多笔转账同时进行了操作，每笔转账的事务应该是隔离的。
- 持久性（Durability）：一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影响，这样就能从任何系统崩溃中恢复过来。通常情况下，事务的结果被写到持久化存储器中。
-
2 核心接口
Spring事务管理的实现有许多细节，如果对整个接口框架有个大体了解会非常有利于我们理解事务，下面通过讲解Spring的事务接口来了解Spring实现事务的具体策略。
Spring事务管理涉及的接口的联系如下：
2.1 平台事务管理器（PlatformTransactionManager）
Spring并不直接管理事务，而是提供了多种事务管理器，他们将事务管理的职责委托给Hibernate或者JTA等持久化机制所提供的相关平台框架的事务来实现。
Spring事务管理器的接口是org.springframework.transaction.PlatformTransactionManager，
通过这个接口，Spring为各个平台如JDBC、Hibernate等都提供了对应的事务管理器，但是具体的实现就是各个平台自己的事情了。
PlatformTransactionManager接口的内容如上图：
主要定义了
getTransaction(TransactionDefinition definition) //获取事务,
commit() //提交,
rollback() //回滚
方法。
而具体实现，我们常用的有：
DataSourceTransactionManager:使用jdbc来进行数据库操作时，对事务进行管理，
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource" /> </bean>
HibernateTransactionManager:使用hibernate进行操作时，对事务进行管理。
<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager"> <property name="sessionFactory" ref="sessionFactory" /> </bean>
2.2 基础事务属性定义（TransactionDefinition）
上面讲到的事务管理器接口PlatformTransactionManager通过getTransaction(TransactionDefinition definition)方法
传入事务属性定义来得到事务，
这个方法里面的参数是TransactionDefinition类，这个类就定义了一些基本的事务属性。
那么什么是事务属性呢？
事务属性可以理解成事务的一些基本配置，描述了事务策略如何应用到方法上。事务属性包含了5个方面，如图所示：
TransactionDefinition接口的内容如上图：
主要定义了
getPropagationBehavior() //获取事务传播行为,
getIsolationLevel() //获取事务隔离级别,
getTimeout() //获取超时时间,
isReadOnly() //事务是否只读
我们可以发现TransactionDefinition正好用来定义事务属性，下面详细介绍一下各个事务属性。
2.2.1 传播行为
事务的第一个方面是传播行为（propagation behavior）。
当事务方法被另一个事务方法调用时，必须指定事务应该如何传播。
Spring定义了七种传播行为：
|
传播行为
|
含义
|
|
PROPAGATION_REQUIRED
|
表示当前方法必须运行在事务中。如果当前事务存在，方法将会在该事务中运行。否则，会启动一个新的事务
|
|
PROPAGATION_SUPPORTS
|
表示当前方法不需要事务上下文，但是如果存在当前事务的话，那么该方法会在这个事务中运行
|
|
PROPAGATION_MANDATORY
|
表示该方法必须在事务中运行，如果当前事务不存在，则会抛出一个异常
|
|
PROPAGATION_REQUIRED_NEW
|
表示当前方法必须运行在它自己的事务中。一个新的事务将被启动。如果存在当前事务，在该方法执行期间，当前事务会被挂起。如果使用JTATransactionManager的话，则需要访问TransactionManager
|
|
PROPAGATION_NOT_SUPPORTED
|
表示该方法不应该运行在事务中。如果存在当前事务，在该方法运行期间，当前事务将被挂起。如果使用JTATransactionManager的话，则需要访问TransactionManager
|
|
PROPAGATION_NEVER
|
表示当前方法不应该运行在事务上下文中。如果当前正有一个事务在运行，则会抛出异常
|
|
PROPAGATION_NESTED
|
表示如果当前已经存在一个事务，那么该方法将会在嵌套事务中运行。嵌套的事务可以独立于当前事务进行单独地提交或回滚。如果当前事务不存在，那么其行为与PROPAGATION_REQUIRED一样。注意各厂商对这种传播行为的支持是有所差异的。可以参考资源管理器的文档来确认它们是否支持嵌套事务
|
可以看到以上有七种事务传播行为，经常使用到的为标注了红色的三种。REQUIRED是使用最频繁的一个。
2.2.2 隔离级别
事务的第二个维度就是隔离级别（isolation level）。
隔离级别定义了一个事务可能受其他并发事务影响的程度。
Spring定义了五种隔离级别：
|
隔离级别
|
含义
|
|
ISOLATION_DEFAULT
|
使用后端数据库默认的隔离级别
|
|
ISOLATION_READ_UNCOMMITTED
|
最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读
|
|
ISOLATION_READ_COMMITTED
|
允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生
|
|
ISOLATION_REPEATABLE_READ
|
对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生
|
|
ISOLATION_SERIALIZABLE
|
最高的隔离级别，完全服从ACID的隔离级别，确保阻止脏读、不可重复读以及幻读，也是最慢的事务隔离级别，因为它通常是通过完全锁定事务相关的数据库表来实现的
|
Spring中，默认使用DEFAULT，即当前连接池中使用的数据库的隔离级别。
Oracle默认的隔离级别为：READ_COMMITTED
Mysql默认的隔离级别为：REPEATABLE_READ
2.2.3 只读
事务的第三个特性是它是否为只读事务。
如果事务只对后端的数据库进行该操作，数据库可以利用事务的只读特性来进行一些特定的优化。
通过将事务设置为只读，你就可以给数据库一个机会，让它应用它认为合适的优化措施。
2.2.4 事务超时
为了使应用程序很好地运行，事务不能运行太长的时间。
因为事务可能涉及对后端数据库的锁定，所以长时间的事务会不必要的占用数据库资源。
事务超时就是事务的一个定时器，在特定时间内事务如果没有执行完毕，那么就会自动回滚，而不是一直等待其结束。
2.2.5 回滚规则
事务五边形的最后一个方面是一组规则，这些规则定义了哪些异常会导致事务回滚而哪些不会。
默认情况下，事务只有遇到运行期异常时才会回滚，而在遇到检查型异常时不会回滚（这一行为与EJB的回滚行为是一致的）
但是你可以声明事务在遇到特定的检查型异常时像遇到运行期异常那样回滚。同样，你还可以声明事务遇到特定的异常不回滚，即使这些异常是运行期异常。
2.3 事务状态
上面讲到的调用PlatformTransactionManager接口的getTransaction()的方法得到的是TransactionStatus接口的一个实现。
TransactionStatus接口的内容如上图：
主要定义了
isNewTransaction(); // 是否是新的事物
hasSavepoint(); // 是否有恢复点
setRollbackOnly(); // 设置为只回滚
isRollbackOnly(); // 是否为只回滚
isCompleted; // 是否已完成
可以发现这个接口描述的是一些处理事务提供简单的控制事务执行和查询事务状态的方法，在回滚或提交的时候需要应用对应的事务状态。
3 事务的实现方式
3.1 编程式和声明式事务的区别
Spring提供了编程式事务和声明式事务两种实现方式，
编程式事务允许用户在代码中精确定义事务的边界，
而声明式事务（基于AOP）有助于用户将操作与事务规则进行解耦。
简单地说，编程式事务侵入到了业务代码里面，但是提供了更加详细的事务管理；而声明式事务由于基于AOP，所以既能起到事务管理的作用，又可以不影响业务代码的具体实现。
代码演示：
