A服务Try执行成功，B服务Try执行成功，在A服务中的confirm抛出一个异常，B服务没有confirm方法，然后A服务的confirm会重试，但是居然会执行B的cancel方法，测试发现

[leecx]

TCC不是应该是Try执行成功，则执行confirm,与cancel就没关系了吧。两个服务的try都执行完成，A服务confirm异常，B服务为什么会执行cancel。

[liuyangming]

有几个问题，需要先确认一下：
1、A服务和B服务，谁调用谁？是否确认在一个全局事务内？
2、A->B或者B->A，是远程调用还是本服务内的调用？如果是服务内的调用，是否使用了REQUIRES_NEW的事务隔离级别？
3、你所说的A执行confirm、B执行cancel的操作，是否在同一个事务内？byteTCC在执行confirm/cancel时会在日志中打印各自归属的全局事务xid，可以用于确认!

一个全局事务内，不会有的服务执行处于commit状态（执行confirm）有的服务处于cancel 状态（执行cancel）。我刚按你所提供的信息构建了一个样例，并不会出现你说的这种情况。

你碰到的这个情况更可能的情况是，执行B.cancel的操作属于另外的请求。成功的那个请求因为B服务没有confirm所以不会打印任何日志，所以没有被看到。当然，这只是目前的推断，如果你发现与你碰到的情况不相符的话，请提供更详细的信息吧。或者，提供一下能重现的步骤。

[leecx]

谢谢了，是我这边搞错了，我把全局事务日志删除后，重新执行不会出现上述问题。
还有想问一下作者，像confirm，cancel重试次数，超时重试，全局事务日志存储等配置在哪呢

[liuyangming]

bytetcc-supports-springcloud-primary.xml/bytetcc-supports-springcloud-secondary.xml中的bytetccBeanFactory，有对大部分部件的引用。其中，compensableRecovery用于执行事务故障恢复；compensableLogger用于记录事务日志。

故障恢复由定时任务执行，其间隔由CompensableWork.recoveryInterval决定，可自定义修改；byteTCC不支持配置重试次数的配置，出错的事务将始终被尝试恢复直至成功，但间隔时间会以指数级别增加。

[leecx]

好的，谢谢了