[5.0.2] LCN TM 通知 TC 失败导致数据不一致 about tx-lcn HOT 17 OPEN

你好 解决了吗？

from tx-lcn.

有自己添加重试机制吗？还是怎么处理的？

from tx-lcn.

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

from tx-lcn.

你直接吞吐异常的话 也是可以人工干预的啊

from tx-lcn.

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

from tx-lcn.

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

都提交了，怎么回滚？

from tx-lcn.

定义一个回滚的接口 具体代码根据业务了

from tx-lcn.

人工干预也是一样的吧？ 要么提交要么回滚

from tx-lcn.

我感觉这里的关键问题当出现提交或者回滚失败的时候要让 A 服务知道。目前主干版本 A 是不知道通知失败的。因为 TM 吞没了异常。由于这不是柔性事务，我觉得即使重试也不适合太长时间和次数，因为这会导致锁表的时间过长。

总之，我觉得让事务发起方 A 知道失败就可以了，这样业务系统使用者就能感知到出现了数据不一致的异常。然后人为去处理就行了

from tx-lcn.

定义一个回滚的接口 具体代码根据业务了

如果回滚还需要接口，那么还不如直接用基于 SAGA 模式的柔性事务实现

from tx-lcn.

我感觉这里的关键问题当出现提交或者回滚失败的时候要让 A 服务知道。目前主干版本 A 是不知道通知失败的。因为 TM 吞没了异常。由于这不是柔性事务，我觉得即使重试也不适合太长时间和次数，因为这会导致锁表的时间过长。

总之，我觉得让事务发起方 A 知道失败就可以了，这样业务系统使用者就能感知到出现了数据不一致的异常。然后人为去处理就行了
A知道了也是人工处理 但看那个aspectLog也是一样的人工处理啊

from tx-lcn.

定义一个回滚的接口 具体代码根据业务了

如果回滚还需要接口，那么还不如直接用基于 SAGA 模式的柔性事务实现

这个只是针对失败场景的处理啊 正常情况或者是基本大部分情况还是走的原来的流程啊

from tx-lcn.

按照流程图

只有“5.响应通知事务组”异常才会有数据不一致的问题，因为B,C异常，事务协调器（T）是能感知的，并且会告知A。

from tx-lcn.

按照流程图

只有“5.响应通知事务组”异常才会有数据不一致的问题，因为B,C异常，事务协调器（T）是能感知的，并且会告知A。

怎么告知？

from tx-lcn.

按照流程图

只有“5.响应通知事务组”异常才会有数据不一致的问题，因为B,C异常，事务协调器（T）是能感知的，并且会告知A。

遗憾的是，实际的实现与这个图有一些差异，当 commit[1] 或 rollback[2] 后时如果出现 RPC 通信异常，那么此处并不会抛出异常

[1]

[2]

from tx-lcn.

看这个#8 发起方的TC会通知TM补偿事务

from tx-lcn.

看这个#8 发起方的TC会通知TM补偿事务

由于RPC 通讯异常，补偿失败时，全局事务的业务发起方无法收到异常，因为异常被 TM 吞没了

from tx-lcn.