undo_log 不能删除的问题

[Foreach1997]

undo_log 不能删除的问题

[funky-eyes]

AT模式一阶段已经提交了事务结果，二阶段只需要删除undolog就可以了，undolog删除失败并不影响事务结果，所以并不应该由于undolog删除失败（你替换了数据源，该节点下找不到datasource进行删除undolog），而将不影响业务的且已经决议提交的事务再次进行回滚。
In AT mode, the first phase has already submitted the transaction result, and the second phase only needs to delete the undolog. The failure to delete the undolog does not affect the transaction result. Therefore, the transaction, which has been decided and committed, should not be rolled back again just because the undolog deletion failed (you replaced the data source, and the datasource cannot be found under this node to delete the undolog)

[funky-eyes]

而且你的版本应该不是1.5.2及以上版本，因为1.5.2开始负载均衡由xid上的serverip所决定，而下发到了b节点而不是a节点，说明决议的server跟创建事务begin时的server不是同一个。
And your version is probably not 1.5.2 or above, because starting from 1.5.2, load balancing is determined by the server ip on the xid. Sending it to node B instead of node A indicates that the server responsible for resolution is not the same as the one when the transaction was created with begin

[Foreach1997]

AT模式一阶段已经提交了事务结果，二阶段只需要删除undolog就可以了，undolog删除失败并不影响事务结果，所以并不应该由于undolog删除失败（你替换了数据源，该节点下找不到datasource进行删除undolog），而将不影响业务的且已经决议提交的事务再次进行回滚。 In AT mode, the first phase has already submitted the transaction result, and the second phase only needs to delete the undolog. The failure to delete the undolog does not affect the transaction result. Therefore, the transaction, which has been decided and committed, should not be rolled back again just because the undolog deletion failed (you replaced the data source, and the datasource cannot be found under this node to delete the undolog)

如果这样不就可能会导致不知道当前事务是否正确的进行提交了吗？

[Foreach1997]

而且你的版本应该不是1.5.2及以上版本，因为1.5.2开始负载均衡由xid上的serverip所决定，而下发到了b节点而不是a节点，说明决议的server跟创建事务begin时的server不是同一个。 And your version is probably not 1.5.2 or above, because starting from 1.5.2, load balancing is determined by the server ip on the xid. Sending it to node B instead of node A indicates that the server responsible for resolution is not the same as the one when the transaction was created with begin

1.5.2以上版本的话 ，容器a开启的全局事务最终会在容器a上进行提交吗

[funky-eyes]

AT模式一阶段已经提交了事务结果，二阶段只需要删除undolog就可以了，undolog删除失败并不影响事务结果，所以并不应该由于undolog删除失败（你替换了数据源，该节点下找不到datasource进行删除undolog），而将不影响业务的且已经决议提交的事务再次进行回滚。 In AT mode, the first phase has already submitted the transaction result, and the second phase only needs to delete the undolog. The failure to delete the undolog does not affect the transaction result. Therefore, the transaction, which has been decided and committed, should not be rolled back again just because the undolog deletion failed (you replaced the data source, and the datasource cannot be found under this node to delete the undolog)

如果这样不就可能会导致不知道当前事务是否正确的进行提交了吗？

哪里导致了不知道是否正确的提交？一阶段已经提交了，二阶段只是删个undolog跟事务结果没有任何影响
Where does the uncertainty about whether the submission is correct arise from? The first phase has already been submitted, and the second phase is just deleting an undolog, which has no impact on the transaction result.

[funky-eyes]

而且你的版本应该不是1.5.2及以上版本，因为1.5.2开始负载均衡由xid上的serverip所决定，而下发到了b节点而不是a节点，说明决议的server跟创建事务begin时的server不是同一个。 And your version is probably not 1.5.2 or above, because starting from 1.5.2, load balancing is determined by the server ip on the xid. Sending it to node B instead of node A indicates that the server responsible for resolution is not the same as the one when the transaction was created with begin

1.5.2以上版本的话 ，容器a开启的全局事务最终会在容器a上进行提交吗

谁在一阶段注册的分支事务，谁进行二阶段处理，如果这个节点在二阶段时不存在才会选择其他节点
Who registers the branch transaction in the first phase, who performs the second phase processing, and only if this node does not exist during the second phase will another node be selected.