Lei Zhang

TM 通知 B 或者 C 失败后吞没了异常，我改成了抛出异常给 A。让业务侧感知到这个问题。此时导致事务不一致是不可避免的。这时就需要人工干预了

> 感觉是不是可以在tc端单独起个线程，如果有通知失败的情况 直接把之前的提交给回滚 都提交了，怎么回滚？

我感觉这里的关键问题当出现提交或者回滚失败的时候要让 A 服务知道。目前主干版本 A 是不知道通知失败的。因为 TM 吞没了异常。由于这不是柔性事务，我觉得即使重试也不适合太长时间和次数，因为这会导致锁表的时间过长。 总之，我觉得让事务发起方 A 知道失败就可以了，这样业务系统使用者就能感知到出现了数据不一致的异常。然后人为去处理就行了

> 定义一个回滚的接口 具体代码根据业务了 如果回滚还需要接口，那么还不如直接用基于 SAGA 模式的柔性事务实现

> 按照流程图 >  > 只有“5.响应通知事务组”异常才会有数据不一致的问题，因为B,C异常，事务协调器（T）是能感知的，并且会告知A。 遗憾的是，实际的实现与这个图有一些差异，当 commit[1] 或 rollback[2] 后时如果出现 RPC 通信异常，那么此处并不会抛出异常 [1] https://github.com/codingapi/tx-lcn/blob/26a429557dc4be1e22a24c61b450286827efe398/txlcn-tm/src/main/java/com/codingapi/txlcn/tm/txmsg/transaction/NotifyGroupExecuteService.java#L71 [2] https://github.com/codingapi/tx-lcn/blob/26a429557dc4be1e22a24c61b450286827efe398/txlcn-tm/src/main/java/com/codingapi/txlcn/tm/txmsg/transaction/NotifyGroupExecuteService.java#L73

> 看这个#8 发起方的TC会通知TM补偿事务 由于RPC 通讯异常，补偿失败时，全局事务的业务发起方无法收到异常，因为异常被 TM 吞没了

Are you using version 0.5.0 and the issue is accidental?

> Yes, but always appear once it happens This question impressed me, you can try to upgrade to 0.6.0

> omega的补偿命令本身是可能执行失败的，alpha端命令的状态处于pending状态，此时服务端不会重新下发命令，但是客户端执行失败是有可能整个服务crash，最后也无法本地重试。最后会导致整个补偿事务一直pending。 我印象中补偿注解 @Compensable 有一个参数 retries 可以控制重试次数，非状态机模式下我没有验证过。 在状态机模式下应该是超过重试次数后会吧这笔事物设置成挂起状态。

你可以在这个文件找到 retries 的定义 https://github.com/apache/servicecomb-pack/blob/master/omega/omega-transaction/src/main/java/org/apache/servicecomb/pack/omega/transaction/annotations/Compensable.java