求助：JDBC回滚失败（Connection is closed）——长事务与查询超时冲突

这个异常的核心矛盾是JDBC查询超时配置与长事务运行需求的冲突：

• JDBC模板的查询超时参数会在SQL执行超时后直接关闭数据库连接
• 此时Spring事务仍处于活跃状态，后续事务回滚操作尝试使用已关闭的连接，就会抛出Connection is closed异常

1. 明确事务超时与JDBC查询超时的差异 #

不要混淆两类超时配置的作用：

• Spring事务超时：控制整个事务的最长运行时间，超时后Spring会主动触发回滚，且能正确管理连接生命周期
• JDBC查询超时：仅控制单条SQL的执行时间，超时后JDBC驱动直接关闭连接，不会通知Spring事务管理器

调整策略：

• 移除JDBC模板的查询超时配置，改用@Transactional(timeout = N)注解设置事务整体超时（N为秒数，需大于事务最长预期运行时间）
• 若必须保留单条SQL的超时控制，需确保该SQL的超时时间小于事务超时时间，避免SQL超时先触发连接关闭

2. 检查连接池配置 #

连接池的空闲连接回收机制可能强制回收长事务占用的连接：

• 查看连接池（如HikariCP、Druid）的maxIdle、removeAbandonedTimeout参数，确保其值大于事务的最长预期运行时间
• 若非必要，禁用连接池的removeAbandoned功能，避免误回收正在使用的连接

3. 优化长事务逻辑 #

长事务本身是风险点，建议从根源优化：

• 将长事务拆分为多个短事务，减少单事务占用连接的时间
• 把非核心操作（如日志记录、第三方调用）移出事务，缩小事务范围
• 优化慢SQL：通过执行计划分析、索引优化缩短SQL执行时间，从根源避免触发超时

4. 增加异常处理逻辑 #

在代码中捕获SQL超时异常，主动标记事务回滚并确保连接正确释放：

try {
    jdbcTemplate.query(...);
} catch (SQLTimeoutException e) {
    TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
    throw new RuntimeException("SQL执行超时", e);
}

• 临时移除JDBC查询超时配置，观察是否还会出现连接关闭的回滚异常
• 逐步调整事务超时和连接池参数，验证长事务的稳定性
• 对优化后的SQL进行压测，确认超时场景不再触发连接异常

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