使用问题

在事务协调器故障的情况下，事务的提交和回滚还能正常进行吗?

事务协调器采用无状态节点，只要没有全部发生故障，就能够正常运行业务（性能会受到影响）。若节点全部故障，事务的提交和回滚也不受影响，重启服务后，事务仍能够正常提交或回滚。

DTF 如何与 TSF 协同使用？

1. 在 Maven pom 文件中修改配置，引入 TSF SDK。
2. 添加一行 @EnableTsf 注解，即可在分布式事务中引入微服务平台相关能力。

使用 TSF 相关能力，请参考 TSF 产品文档。

在 TCC 模式中，Confirm 和 Cancel 可能和 Try 并行甚至在 Try 之前执行吗？

可能出现。例如空回滚问题和悬挂问题。

• 空回滚问题描述：Try 未执行时，Cancel 执行。
• 空回滚问题解决方案*：Cancel 操作判断一阶段是否已执行，识别空回滚后，直接返回成功；具体来讲：需要一张额外的事务控制表，其中有分布式事务 ID 和分支事务 ID，第一阶段 Try 方法里会插入一条记录，表示一阶段执行了。Cancel 接口里读取该记录，如果该记录存在，则正常回滚；如果该记录不存在，则是空回滚。
• 悬挂问题描述：Try 超时，执行 Cancel，Try 接口恢复。出现的原因是 Try 由于网络拥堵而超时，事务管理器生成回滚，触发 Cancel 接口，而最终又收到了 Try 接口调用，但是 Cancel 比 Try 先到。
• 悬挂问题解决方案*：按照前面允许空回滚的逻辑，回滚会返回成功，事务管理器认为事务已回滚成功，则此时的 Try 接口不应该执行，否则会产生数据不一致，所以我们在 Cancel 空回滚返回成功之前先记录该条事务 xid 或业务主键，标识这条记录已经回滚过，Try 接口先检查这条事务xid或业务主键如果已经标记为回滚成功过，则不执行 Try 的业务操作。

在 TCC 模式中，是否需要考虑幂等？

需要考虑幂等问题。

幂等问题的解决方案为：DTF 框架会在 Confirm 和 Cancel 执行后将事务状态改为已提交或已回滚状态，因此，重复调用在 Confirm 和 Cancel 接口时，先获取状态，如果已执行，直接返回成功。

如果调用链为 A->B->C，B.try 报错，A.cancel，B.cancel，C.cancel 哪些会执行？

B 的 Try 报错，因此 C 的 Try 还未操作，因此事务协调器会发起对 A 与 B 的 Cancel。A 与 B 的 Cancel 无先后顺序。

总结：事务协调器发起 Confirm 与 Cancel 操作均无先后顺序，在 Try 成功/失败后，后续阶段的顺序本身无意义。无需执行能够带给您更高性能。

如果 Confirm 或者 Cancel 报错，重试机制是怎样的？

会有三次重试。分为两种情况：

• 情况一：Confirm/Cancel 逻辑有误，TC 下发 Confirm/Cancel 请求5秒内客户端无响应，此时会立刻开始下一次重试。若三次重试请求下发5秒内客户端都无响应，则本条主事务状态变为异常事务。
• 情况二：闪断和节点故障导致的。即 TC 下发 Confirm/Cancel 请求后客户端有响应，则会等待15分钟。以下为每一次客户端都成功响应的兜底重试策略。 第一次 Confirm 或 Cancel（非重试），持续15分钟。若超时，在1秒后开始第一次重试，持续15分钟；若依然超时，等待2秒开始第二次重试，持续15分钟；若还是超时，等待3秒开始第三次重试15分钟。若依然失败，则转为异常事务。

如果 Try 超时了，框架是否会回滚 Try 的本地事务并阻止后续调用链？

会回滚，需要注意实现幂等以及防悬挂可空回滚。会阻止后续调用。

FMT 接入模式下是否支持操作没有主键的数据库？

不支持操作没有主键的数据库。为了开发及使用的方便，请选择具有主键的数据库。

TCC 与 FMT 能否嵌套使用？

在 TCC 事务下，可嵌套 TCC 与 FMT 子事务。

在 FMT 事务下，可嵌套 FMT 子事务，不可嵌套 TCC 子事务（暂时不支持，在后续支持其他类型子事务，如非 DB 操作的 FMT 子事务，也可能产生 FMT 下 TCC 事务的主子关系）。

在一个主事务中，TCC 与 FMT 子事务支持混用。

使用 Apach 的 Sharding jdbc 报错如何处理？

DTF 的 FMT 模式暂时不兼容 Sharding jdbc，在 FMT 模式下会出现兼容性问题。如果您只需要使用 TCC 模式，可参考开发文档 - 客户端配置，配置 dtf.env.fmt 为 false 以解决该问题。