TCC-Transaction 分布式事务源码解读（四、框架感知Tcc服务后具体做了哪些事）

位置3、在所拦截方法的前后执行3中的@compensable  TransactionInterceptor.interceptCompensableMethod(pjp)代码（后续重点解读该处代码）那么接下来继续分享位置3中的代码是如何执行的？

位置1：根据注解中的事务传播特性、事务是否已激活、transactionContext 来计算当前方法是ROOT、还是PROVIDER或者是NORMAL，具体计算逻辑如下（1、传播特性REQUIRED并且未被激活，那么肯定是第一次创建事务，所以应该是ROOT类型 或者要重新创建一个事务那么新创建的则为ROOT。 2、如果传播特性是REQUIRED或者MANDATORY 且事务未被激活且transactionContext不为空则返回PROVIDER。3、为NORMAL

位置2：rootMethodProceed(pjp, asyncConfirm, asyncCancel); 方法中具体是做了哪些事？且看下图源码

位置2.1：且看transactionManager.begin();中的源码具体做了哪些事。

位置2.11：创建了一个Transaction对象，并将将Transaction保存至表中，transactionRepository是由使用TCC分布式事务的业务方配置，本文以JdbcTransactionRepository为例，看看具体是如何保存的，且看源码。

位置2.12：将Transaction对象注册到队列中,且看如何保存。

总结：位置2.1：rootMethodProceed方法中transactionManager.begin();做的事是创建transaction对象，并且将transaction保存至数据库成功后将其注册到队列中。

位置2.2：调用业务方法做业务处理，即调用try方法做业务处理，若业务处理报异常则进行位置2.3中的rollback处理，若业务处理完成则进行2.4中的commit操作。（猜想rollback/commit应该是更新表中transaction中的状态，且看具体是否这样？）

位置2.3：下图2.31中去update 表中transaction的状态为CANCELLING，2.32中rollback 通过反射去调用TCC中的cancel方法回滚业务事务（1、ConfigurableCoordinatorAspect AOP切面中会分析如何拿到TCC中cancel方法名以及目标类的。2、看到这里有人会问update transaction的为CANCELLING和调TCC中的cancel方法不在同一个事务里，transaction数据更新成功了，TCC cancel失败了怎么办呢？？其实这个问题也将在下一个TCC补偿里讲解）。

位置2.4：业务处理完成则commit修改transaction状态且调用TCC中配置的confirm方法进行业务确认。2.41更新transaction中的状态为confirming，2.42中调用TCC中的confirm方法进行业务确认（1、ConfigurableCoordinatorAspect AOP切面中会分析如何拿到TCC中confirm 方法名以及目标类的，失败进行TCC补偿）。

位置2.5：一次事务结束应该是将事务从队列中删除，具体看如下代码

 

总结：本文主要讲解TCC框架感知到@compensable 注解后具体是做了哪些事？

1、创建Transaction 对象，并保存至表中，保存成功后将Transaction注册到队列中

2、将调用业务方法，即TCC中的try业务

3、若业务失败则更新Transaction状态为CANCELLING,且调用TCC中的cancel方法回滚业务（支持失败重试）

4、若业务成功则更新Transaction状态为confirming,且调用TCC中的confirm方法确认业务（支持失败重试）

5、调用结束将当前Transaction从队列中删除