Apache Seata 在 PostgreSQL XA 模式下的超时回滚问题分析

问题背景

在分布式事务处理框架 Apache Seata 的 XA 模式中，当使用 PostgreSQL 数据库时，如果事务超时（默认一分钟），事务发起者服务可能会出现回滚失败的情况。这个问题源于 PostgreSQL JDBC 驱动对 XA 事务处理的特殊实现方式。

问题本质

问题的核心在于 PostgreSQL 的 XA 连接实现类 PGXAConnection 在处理回滚操作时的逻辑判断。当 Seata 尝试回滚一个超时事务时，会调用 PGXAConnection.rollback(Xid) 方法，该方法内部会检查当前连接是否持有与回滚请求匹配的事务 ID：

if (currentXid != null && currentXid.equals(xid))

然而，Seata 的 XABranchXid 类没有重写 equals 方法，导致这个判断总是返回 false。结果就是 PostgreSQL 驱动没有执行真正的回滚操作，而是将连接设置为自动提交模式，实际上提交了本应回滚的事务。

技术细节分析

在 Seata 的 XA 模式中，事务处理分为几个关键阶段：

1. 一阶段：事务发起者执行本地事务但不提交
2. 二阶段：根据全局事务状态决定提交或回滚

在正常情况下，Seata 不会在一阶段持有数据库连接。但在超时情况下，可能出现一阶段尚未完成时就需要执行回滚的特殊场景。此时：

1. Seata 会通过 AbstractDataSourceProxyXA.getConnectionForXAFinish 方法获取持有待提交事务的连接
2. 该连接中已经包含了当前事务的 XID（currentXid）
3. 由于 equals 方法比较失败，导致回滚逻辑被跳过

解决方案

经过社区讨论，确定了以下修复方案：

1. 在 ConnectionProxyXA.xaRollback 方法中优先使用已存在的 xaBranchXid
2. 只有当 xaBranchXid 为空时才创建新的 XID 对象

修复后的核心逻辑如下：

public synchronized void xaRollback(String xid, long branchId, String applicationData) throws XAException {
    if(xaBranchXid != null) {
        xaRollback(xaBranchXid);
    } else {
        XAXid xaXid = XAXidBuilder.build(xid, branchId);
        xaRollback(xaXid);
    }
}

技术启示

这个问题揭示了分布式事务框架与不同数据库驱动实现交互时需要注意的几个关键点：

1. 对象相等性比较：在实现 XID 等跨系统交互对象时，必须谨慎实现 equals 和 hashCode 方法
2. 连接生命周期管理：需要清晰定义在事务各阶段对数据库连接的持有策略
3. 异常处理：特别是超时等边界情况下的处理逻辑需要特别关注

对于使用 Seata 的开发人员，建议在 PostgreSQL XA 模式下：

1. 合理设置事务超时时间，避免默认值不适合业务场景
2. 关注事务监控，及时发现和处理异常情况
3. 及时升级到包含此修复的版本

此问题的修复确保了 Seata 在 PostgreSQL XA 模式下能够正确处理超时回滚场景，增强了分布式事务的可靠性。