We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TCC不是应该是Try执行成功,则执行confirm,与cancel就没关系了吧。两个服务的try都执行完成,A服务confirm异常,B服务为什么会执行cancel。
The text was updated successfully, but these errors were encountered:
有几个问题,需要先确认一下: 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所以不会打印任何日志,所以没有被看到。当然,这只是目前的推断,如果你发现与你碰到的情况不相符的话,请提供更详细的信息吧。或者,提供一下能重现的步骤。
Sorry, something went wrong.
谢谢了,是我这边搞错了,我把全局事务日志删除后,重新执行不会出现上述问题。 还有想问一下作者,像confirm,cancel重试次数,超时重试,全局事务日志存储等配置在哪呢
bytetcc-supports-springcloud-primary.xml/bytetcc-supports-springcloud-secondary.xml中的bytetccBeanFactory,有对大部分部件的引用。其中,compensableRecovery用于执行事务故障恢复;compensableLogger用于记录事务日志。
故障恢复由定时任务执行,其间隔由CompensableWork.recoveryInterval决定,可自定义修改;byteTCC不支持配置重试次数的配置,出错的事务将始终被尝试恢复直至成功,但间隔时间会以指数级别增加。
好的,谢谢了
No branches or pull requests
TCC不是应该是Try执行成功,则执行confirm,与cancel就没关系了吧。两个服务的try都执行完成,A服务confirm异常,B服务为什么会执行cancel。
The text was updated successfully, but these errors were encountered: