注入的JOOQ Context引发数据库连接泄漏问题排查

先直接点出核心问题：你代码里的jooq.close()是导致连接泄漏的关键错误操作，而且这完全没必要。

为什么手动close会出问题？ #

当你通过CDI注入DSLContext时，这个实例的生命周期应该交由容器管理——尤其是在Wildfly默认的JTA事务环境下。jOOQ的DSLContext.close()方法会直接关闭或归还底层数据库连接，但如果容器还在管控这个连接的生命周期（比如事务尚未完成），手动关闭会打破容器的连接管理逻辑，导致连接无法被正确回收，最终引发泄漏。

修正后的代码写法 #

直接删掉finally块里的jooq.close()调用，让容器自动处理连接的释放：

public class Foo { 
    private @Inject DSLContext jooq; 

    public boolean update() { 
        try { 
            jooq.doStuff(); 
            // 事务逻辑交给容器管理，无需手动干预连接
        } catch(Exception e) { 
            System.out.println(e.getCause().getMessage()); 
            // 可根据需求触发事务回滚，或交由容器自动处理
        } 
        // 移除手动close操作
    } 
}

你可能遗漏的CDI配置 #

要确保注入的DSLContext是事务感知的，和Wildfly的JTA事务绑定：

• 配置jOOQ使用JtaTransactionProvider，让jOOQ自动关联容器的JTA事务，连接会在事务提交/回滚时自动归还到连接池。
• 正确编写DSLContext的CDI生产者方法，从Wildfly的JNDI数据源获取连接，并绑定事务：

@Produces
@RequestScoped // 可根据业务需求选择合适的作用域
public DSLContext createDSLContext() {
    // 从Wildfly配置的JNDI数据源获取连接，示例路径需替换为你的实际配置
    DataSource dataSource = InitialContext.doLookup("java:jboss/datasources/YourPostgresDS");
    return DSL.using(dataSource, SQLDialect.POSTGRES, new Settings()
        .withTransactionProvider(new JtaTransactionProvider()));
}

• 如果使用jOOQ官方的CDI扩展（jooq-cdi依赖），确保已正确引入依赖，且扩展被Wildfly容器激活，它会自动创建事务感知的DSLContext实例。

额外检查点 #

• 确认Wildfly数据源配置了合理的连接池参数（比如最大连接数、连接超时时间等），避免因池配置不当放大泄漏问题。
• 排查是否有其他代码手动获取数据库连接但未正确归还，但根据你的示例，最可能的根源就是手动关闭了CDI注入的DSLContext。

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