因无连接致提交失败时的回滚行为异常及连接池损坏问题

首先，你的判断完全正确——回滚一个从未成功获取到连接的事务时，EclipseLink去重新获取新连接的逻辑确实毫无意义，这是它在外部连接池适配上的设计缺陷。

问题本质拆解 #

当事务提交阶段因HikariCP连接超时失败时，此时事务实际上从未真正启动（因为连数据库连接都没拿到），根本没有需要回滚的数据库事务状态。但EclipseLink的DatasourceAccessor在处理回滚时，错误地将内存中标记的"active"事务状态等同于存在有效数据库连接，强行触发重新连接逻辑；而HikariCP默认的autocommit=true与回滚操作的预期（autocommit=0）冲突，直接导致健康连接被误标记为损坏。

为什么EclipseLink会有这种设计？ #

这个逻辑大概率是为了兼容早期本地连接池场景，或者假设只要事务标记为"active"就一定持有有效连接。但在外部连接池（比如HikariCP）的场景下，事务的"active"状态只是EclipseLink的内存标记，并不代表真正拿到了数据库连接，这就造成了逻辑错位。

可行的解决方案 #

针对这个问题，你可以从以下几个方向入手解决：

1. 提前判断连接状态，跳过无效回滚

在执行txn.rollback()之前，先检查是否真正持有有效数据库连接，避免无意义的回滚操作：

try { 
    txn.begin(); 
    entityManager.persist(someEntity); 
    txn.commit();
} catch(Throwable tx ){ 
    if(txn.isActive()){
        // 从EntityManager中获取EclipseLink Session，检查连接状态
        Session session = entityManager.unwrap(Session.class);
        DatabaseAccessor accessor = ((ClientSession)session).getAccessor();
        // 仅当存在有效连接时才执行回滚
        if(accessor.getDatasourceConnection() != null && accessor.isConnected()){
            txn.rollback();
        }
        // 无有效连接时直接跳过，因为没有需要回滚的实际事务
    } 
}

2. 自定义DatasourceAccessor覆盖错误逻辑

继承DatasourceAccessor，重写incrementCallCount方法，在回滚场景下跳过重新连接的逻辑：

public class CustomDatasourceAccessor extends DatasourceAccessor {
    @Override
    public synchronized void incrementCallCount(AbstractSession session) {
        // 回滚场景下，仅当存在有效连接时才执行后续操作
        if(session.getTransaction().isRollbackOnly()){
            if(this.datasourceConnection == null || !isConnected()){
                throw DatabaseException.databaseAccessorNotConnected();
            }
            this.callCount++;
        } else {
            // 非回滚场景沿用原逻辑
            super.incrementCallCount(session);
        }
    }
}

之后通过EclipseLink的配置文件指定使用这个自定义Accessor。

3. 提交EclipseLink Bug推动官方修复

由于这个问题在最新版本的EclipseLink中仍然存在，你可以在EclipseLink官方Issue Tracker提交Bug报告，详细描述场景、影响和代码追踪结果，推动官方修复这个逻辑漏洞。

4. 临时调整HikariCP配置（不推荐）

虽然可以将HikariCP的autoCommit设置为false来避免回滚时的异常，但这会改变连接池的默认行为，可能引发其他未知问题，因此仅建议作为临时应急方案。

总结 #

你的理解完全正确，回滚未获取到连接的事务时，获取新连接的操作确实没有意义，反而会破坏连接池的健康连接。上面的方案中，提前判断连接状态跳过无效回滚是最快捷且风险最低的临时解决方案，而自定义Accessor或推动官方修复则是更彻底的解决方式。

内容的提问来源于stack exchange，提问作者user20507