SPRING 事务源码解析

事务一定也是通过对自定义标签进行解析，同时对事务中方法采用 AOP 拦截方法执行代码逻辑，同时针对数据库不同的场景进行对应的提交或回滚操作。

事务标签解析

这里事务标签的解析类似于 4.1 AOP自定义标签的解析过程，在其对应的parse方法中，更多的是交给了AopAutoProxyConfigurer来进行对应自动化代理类注册。
Spring事务是以AOP为基础的，这里注册了代理类和三个bean
注册的代理类为InfrastructureAdvisorAutoProxyCreator。

image.png

注册的三个Bean为BeanFactoryTransactionAttributeSourceAdvisor，TransactionInterceptor 以及AnnotationTransactionAttributeSource。

image.png

这里的Advisor分为PointCutAdvisor和IntroductionAdvisor；二者在判断所有增强器是否可以应用于当前bean时有不同的逻辑，如果当前advisor为prointCutAdvisor走一套逻辑，
如果是IntroductionAdvisor时走另一套逻辑。也就是说，在事务标签解析的时候就注册了事务增强器对应的属性判断和匹配检查使用的对象，也就是BeanFactoryTransactionAttributeSourceAdvisor。

在 TransactionAttributeSourcePointCut的matcher方法中对传入方法进行了computeTranscationAttribute计算
• 方法上寻找事务标签；
• 方法所在类中寻找事务标签；
• 方法对应接口中寻找食物标签
从而实现了不但对方法进行了匹配，对对应类或接口也实现了匹配。将类或接口上的事务配置延伸到了类的每个函数

事务增强器

通过上面的事务标签的解析，我们也在获取bean时根据对应标注返回了需要进行各种增强的代理类对象(如JDK代理)；后面对代理类的调用会逐步走到对应invoke方法中来，
也就是说事务的TransactionInterceptor#invoke实现了事务增强的核心逻辑。
我们在自己实现对应JDK代理的时候，对应代理类要实现InvocationHandler接口，这里是不是在实现接口的类中包含了对应事务拦截器对象，并调用该对应的invoke方法？

事务增强处理主要在如下步骤：
• 获取配置的transactionManager;
• 获取事务属性，并根据事务属性来进行不同的方式处理（编程式事务和声明式事务）；
• 执行前获取事务并收集事务信息；
• 执行目标方法；
• 出现异常则尝试异常处理；
• 提交事务前清除事务信息；
• 提交事务。

事务信息收集

1.构造新的事务链接点，也就是当前需要开启事务的方法名称标识；
2.获取交易状态，也就是我们说的事务；
3.构建事务信息,这里可以理解成简单的Set封装。
下面我们重点说一下对应交易状态的获取：

image.png

从上面代码中框架中我们能够看到，整体来说先获取事务，如果非已存在事务则新建事务状态并初始化，如果是已经存在的事务则走已存在事务处理逻辑。
不存在事务场景：
我们先通过doGetTransaction来获取初始事务，将对应dataSource封装到ConnectionHolder中。
后续通过doBegin来进行事务生成：

image.png

已存在事务场景：
对于已经存在事务的场景，则涉及到Spring事务的传播机制。我们从getTransaction开始分析各种事务传播机制；
PROPAGATION_MANDATORY :外层必须有事务，否则异常退出。

image.png

接下来我们分析存在事务场景中其他事务传播机制：
PROPAGATION_NEVER:外层不允许有事务，否则异常退出。
PROPAGATION_SUPPORTED: 不论外层是否有事务，均同步激活事务执行；也就是说，当外层有事务的时候则直接采用外层事务执行，否则不起事务。
PROPAGATION_REQUIRES_NEW: 不论外层是否有事务，均需要另起新的事务执行。开启新事务前会挂起外层事务。
PROPAGATION_NESTED: 嵌套事务场景，允许有保存点；各嵌套事务各自回滚，互不影响。前提是需要在各自事务内处理对应回滚不将异常外抛。否则也将全部回滚。

image.png

事务的隔离级别：
脏读：A事务读取了B事务修改但尚未提交的数据，后续该数据被B回滚掉，导致A读取了无效数据；
不可重复读：A事务中执行相同的查询多次，每次查询结果都不相同。在于多次读取间，数据被其他事务修改；
幻读：A事务执行了多次查询，后次查询发现并没有之前查询的数据。因为多次读取间，数据被新增或删除了。

image.png

事务回滚

image.png

什么场景下会自动回滚？我们又是否可以不采用自动的模式？后一种答案应该是肯定的，毕竟我们可以通过标签属性
rollbackFor=Exception.class来设置抛出何种类型异常时事务执行回滚而不是提交操作。
-- 自动回滚默认条件：ex Instanceof RuntimeException || ex Instanceof Error

事务回滚处理代码逻辑如下：

image.png

可以从代码中看出，事务的回滚主要有3个分支：

1. 存在保存点的场景，直接回滚到保存点；
2. 新事务则不啰嗦，直接回滚。
3. 事务存在嵌套场景下，当前事务的回滚，只是标记回滚状态，等到事务提交的时候统一不提交。

那么在事务提交的时候一定需要判断事务是否打上了回滚标识，有标识的一定不提交。
在上面代码最后我们看到finally中的一个调用cleanupAfterCompletion(status),这里做的是事后信息的清除：
• 数据库链接的释放；
• 当前线程和事务的解绑；
• 改事务提交模式为自动提交；
• 重置数据库链接等。

事务提交

提交代码做了什么？应该是connection.commit;也就是调用数据库链接的提交。
但整个提交真的就是无脑提交么？这里一定不是，至少我们能想到前面我们回滚的时候如果存在嵌套事务，我们只是标识的子事务需要被回滚。这里一定会判断标识，如果是要回滚，一定不可提交。

image.png

同样，我们发现提交并不仅仅是判断嵌套事务是否回滚。还有下面判断：

1. 存在保存点则恢复到保存点，不提交事务；

2. 非最外层新事务或require_new事务不会进行提交，会等最外层新建事务整体提交。

   
   
   image.png