一 .导读

首先放一张tm模块的主要类关系图

从图中可以很明显的看出 模块暴露出去的类是 TransactionalTemplate 模板类中找 GlobalTransactionalContext 类获取业务业务类 而业务类持有了一个 TrancationManagerHolder 类 即由 TransactionManager 的实现类封装成的单例持有类 holder 通过SPI的方式加载配置文件中配置的具体的 TransactionManager 的实现类 0.9的版本默认实现类是 DefaultTransactionManager 这个类即模板方法处理业务的类。

上面这五个类 真正有用的就是两个类 一个template和一个defaultTransactionManager 一个模板方法类 一个具体的业务实现类 而tm封装这么多 是为了增加扩展点 为将来的扩展留下空间。

比如你可以修改SPI配置文件中 TransactionManager 的实现类 来扩展模板方法的实现。甚至你还可以替换 GlobalTrancationalInterceptor(Spring模块) 中持有的 TrancactionalTemplate 彻底告别tm模块 自己实现具体的业务。

首先是 template 模板参数需要的类 TransactionalExecutor 这是一个接口类

execute()是用来执行业务逻辑的类 而 getTransactionInfo() 用来获取 GlobalTransactional 注解的信息。
GlobalTransactionalInterceptor 在调用模板类的 execute(transactionalExecutor)方法的时候 注入了业务执行逻辑的类和从注解上获取到的信息 即实现了上面的接口类 是匿名类的形式。

TransactionalExecutor 接口类中还有一个子类 即 Exception 的子类 ExecutionException 是对执行时异常的封装。

还有一个enum类 对失败步骤记录状态的集合的封装。

接下来是 TransactionInfo 类 类中的属性用来记录 GlobalTransactional 的信息 注解中的 rollbackFor 和 noRollbackFor 的异常类 根据一场的类名 封装成了 RoolbackRule 和 NoRollbackRule NoRollbackRule 是 RollbackRule 的子类 info类中有一个判断参数中异常类是否要回滚的遍历的方法很有意思

这个方法中有一个很重要的 deepest 刚开始我还以为这个变量没什么用 因为只要返回 boolean 不需要知道到底是 roolbackRules 中的哪一个起作用了 还在github上提了一个 pr 结果被大佬教育了。。。

其实这里 deepest 是用来确定 winner 的是子类 父类的 depth 会高一点。而 roolbackRules中放置的是回滚和不回滚的类的集合。

roolbackRules这个集合是 LinkHashSet 即如果有相同的异常(因为RollbackRule重写了 hashcode(exceptionName) 所以这里的相同是指 exceptioName 相同 后面的类会覆盖前面的 在 template 类中 解析注解 GlobalTransactional 顺序是先解析回滚的 再解析不回滚的 所以这里如果回滚的和不回滚的有相同的异常 最终效果是不回滚。

模板类的 execute(TransactionalExecutor) 方法很清晰 下面一步一步的来分析

1.获取当前的全局事务(能获取到xid)或者创建一个全局事务(xid暂时为空) 全局事务有一个属性 enum 类型 有两个角色 一个是 Launcher 一个是 Participant 即发起者或者参与者。

2.开始全局事务 这里最终会调用 DefaultTransactionManager 即 TM 去向 TC 注册全局事务 获取注册的状态 如果成功会有 xid 并绑定到上下文中。参与者全局事务在注册之前就可以获取到xid。

3.执行业务就不说了 直接看如果执行业务出现异常 这里需要根据 TransactionInfo( GlobalTransaction) 的 roolbackOn(ex) 判断是否是需要回滚的异常 如果不是 执行4提交事务。如果是 则调用DTM进行异常的回滚 并且获取本次回滚后的状态 绑定到属性中 并抛出异常。

4.上报事务的提交结果。角色是参与者的事务是没有职责上报状态的。

5.移除所有的Hook类 即钩子类。

上述模板流程 如果是成功的 则返回执行结果 如果是失败的 则抛出导致失败的异常 交给上层处理。

上层调用类 GlobalTransactionInterceptor 也没有对业务产生的异常进行处理 直接抛给了上层。这里的上层即是 srping 管理的范围 spring 会对异常进行处理。

在 template 方法中 如果因为 seata 框架对事务流程的处理而抛出的异常 则由模板类封装对应的异常 上述5个步骤 每一个步骤都有对应的异常 模板方法把异常抛给 GlobalTransactionInterceptor 在这个类中 先是调用 DefaultFailureHandlerImpl 处理 然后再抛给上层 即 spring 处理。

现在的版本0.9 有一个 failureHandler 的默认处理类 DefaultFailureHandler 这个类维持了一个 HashedWheelTimer(netty包中) 周期性执行任务的线程池类 目前池中只实例化了一个线程。这个类和 newSchedulerThreadPool 生成的线程池类似 都是周期性的执行任务 seata没有自己写周期性执行任务的线程池 而是复用了netty的。

这个线程池的任务是输出当前事务的状态 即 DefaultGlobalTransaction 中 status 的状态

这里对事务状态的判断比较难理解 这里用提交失败处理来分析
当发生 onCommitFailure 给线程池增加一个任务

timer.newTimeout(new CheckTimerTask(tx, GlobalStatus.Committed), SCHEDULE_INTERVAL_SECONDS, TimeUnit.SECONDS);

shouldShop()中会判断 interceptor 传递过来的 tx 中 status 的状态 是否是 GlobalStatus.commited 即是否是提交完成的状态。

这里肯定不会是提交完成的状态 因为提交完成不会抛出异常 就不会进入 failureHandler 的处理方法中。所以 tx 中的 status 的状态和 required 不一样 返回false 这个 run() 方法结束。

这里另起一个线程 主要是为了进行状态的校验 确定一下失败操作是否是正确的 并且输出日志

LOGGER.info( transaction[ tx.getXid() ] current status is [ status ] );

结合上面 onCommitFailureHandler() 中的日志

LOGGER.warn( Failed to commit transaction[ tx.getXid() ] , cause);

一个警告级别 输出未能提交事务的异常原因 一个info级别 输出当前事务的状态。便于定位处理异常。

至此 tm 模块就分析完了 这个模块代理被 GlobalTransaction 注解的方法 纳入自己的事务处理中。
对外表现是
1.提供了 template 模板处理流程的方法 供 spring 模块的 interceptor 调用。
2.代理了业务类 等于包裹了业务类 业务类的前置后置都有处理逻辑。
3.发生业务异常时 事务流程处理完毕 还会把异常抛给上层 即 spring 处理。

更多好文请关注微信公众号 我手一杯