您好，想请教一下TCC模式回滚时候的服务端的调用顺序问题
场景描述：
假设有上层的应用A和a方法，会调用下游的应用B、C的tryB()，tryC()方法
class A{
void a(){
for(1:10){
call B.tryB();
}
for(1:10){
call C.tryC();
}
}
}
class B{
void tryB(){
}
void commitB(){
}
void cancelB(){
}
}
class C{
void tryC() {
}
void commitC(){
}
void cancelC() {
}
}
问题：
如果在tryC的执行的10次循环中第5次失败了，那么server在回调cancel方法是会按什么方式回调（不考虑网络问题）？是会按分支事务的注册顺序，逆序串行调用，还是并发调用？如果是并发的，那是不是对于回滚时候有数据依赖场景，即必须先回滚这个再回滚另外一个的这种，是不是saga更适用？
期待您的回复。
3条答案
按热度按时间wa7juj8i1#
2.0上是顺序（单纯是因为写错了），其余版本都是逆序。2.0开始支持不同resource的并行下发以提升性能，默认并发开关为关闭。
属于依赖场景，本身就是逆序回滚，跟事务模式没什么关系。
2.0 is the order (simply because of a mistake), and the rest of the versions are in reverse order. 2.0 starts to support parallel distribution of different resources to boost performance, and the default concurrency switch is off.
It belongs to the dependency scenario, which is itself a reverse rollback and has nothing to do with the transaction mode.
yhuiod9q2#
感谢答疑，还想请问一下怎么理解写错了？是bug还是？请问目前新版本上是逆序执行吗？
olhwl3o23#
感谢答疑，还想请问一下怎么理解写错了？是bug还是？请问目前新版本上是逆序执行吗？
2.0这个版本做并性下发的时候写错成了顺序了，2.1恢复回逆序
When the version 2.0 was released, it was written in the wrong order, and 2.1 was restored to reverse order.