provider端如果在confirm中抛异常，会错误的执行provider端的cancel逻辑。

[beyondbbk2021]

复现条件：就用提供的demo，非simplified模式tcc，try阶段正常，provider端在confirm中抛异常，过一段时间provider端的cancel逻辑会被错误的调用。

初步分析：provider端会定时调度方法org.bytesoft.bytetcc.TransactionRecoveryImpl#branchRecover，此方法会去调用consumer端的/revocer接口，但拿到的是一个空xidArray，后续一系列逻辑会导致provider端的cancel逻辑被调用，代码如下：

consumer端/recover接口相关代码如下：

最关键的就是这里为啥consumer端的getTransactionRepository得到的transactionList为空？

附上我用的demo：

链接: https://pan.baidu.com/s/1Sr0mk9O58VehoxFnHAlINQ 提取码: f6pz

[FansinZhao]

我已收到您的邮件！谢谢

[liuyangming]

我已收到您的邮件！谢谢

你好，我没有单独给你发送邮件。

你提到的这个问题，provider去调用consumer端的recover只用作一个用途，即provider端用于确认自己当前的分支事务是否为有效（因为上一级节点很可能已经完成了该全局事务）。此时返回null或者空数组，则说明上一级节点事务已经处理完毕，因此该节点上由上一级节点传播而来的分支事务，会被回滚掉。

如果你发现这个操作使得你数据不一致收到影响，可能也说明处理上有所疏漏，还请你提供一下更详细的操作步骤，以便我能复现该问题。谢谢！

[beyondbbk2021]

感谢作者百忙之中耐心回复我的问题。对于作者的这句回复：此时返回null或者空数组，则说明上一级节点事务已经处理完毕，因此该节点上由上一级节点传播而来的分支事务，会被回滚掉。 我仍然还有以下疑问：

当上一级节点事务已经处理完毕，confirm成功也属于完毕的一种。那么由上一节点传播而来的当前节点，这种情况下是不是该努力也尝试confirm，而不是回滚呢？

我跟了下代码，当consumer端confirm正常执行完毕时，会删除TransactionRepositoryImpl中的xidToTxMap，此清理操作就会导致provider端confirm失败后重新尝试时，通过/recover接口拿到的数组为空，继而执行回滚动作。

[liuyangming]

该问题已于0.5.12版本中予以修复，请更新至最新版本。