集成Spring Atomikos连接框架后createStatement报Statement already closed错误

1. 异常核心触发点是Atomikos 4.0.56的连接代理逻辑和MySQL 5.1.30版本驱动的JDBC4StatementWrapper.isClosed()方法实现冲突导致的。日志中持续输出的transaction manager not running警告说明你的数据库操作没有运行在Spring托管的事务上下文中，是触发问题的前置条件。
2. Atomikos的连接代理会将被外部变量持有强引用的Statement加入内部维护列表，每次调用createStatement()时都会先执行purgeClosedStatements逻辑清理已关闭的Statement，清理过程中会调用Statement的isClosed()方法判断状态。
3. 你当前使用的MySQL驱动版本的JDBC4StatementWrapper.isClosed()存在bug：当所属连接无关联活跃事务时，即使Statement本身未关闭，该方法也会错误返回true，导致Atomikos误判Statement已关闭，抛出对应异常。
4. 两种写法的表现差异原因：
   • 链式调用connection.createStatement().executeQuery(query)时，Statement对象是临时对象，没有被外部强引用持有，Atomikos不会将其加入内部维护列表，不会触发purge检查逻辑，因此不会报错。
   • try-with-resources语法会将资源的作用域限定在try块内，Statement不会被外部变量长期持有，同样不会触发purge检查的冲突逻辑，因此可以正常运行。

• 优先推荐使用try-with-resources管理JDBC资源：这是JDBC规范原生推荐的资源管理方式，比手动编写finally块关闭资源更可靠，不会出现资源泄漏问题，完全可以替代你当前的手动关闭逻辑。
• 若业务要求必须在外部持有Statement引用：可以给对应数据库操作方法添加@Transactional注解，让操作运行在Spring托管的事务上下文中，即可规避驱动isClosed()方法的bug。
• 若无法添加事务注解：可以在创建Statement后主动调用一次stmt.isClosed()忽略返回值，提前触发驱动内部逻辑，避免Atomikos检查时报错。
• 若有权限调整依赖版本：将MySQL驱动升级到5.1.38及以上版本，该版本已修复JDBC4StatementWrapper.isClosed()的错误返回问题。

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