连接泄露，请教一下分布式事务的配置是否有问题 about fastdep HOT 8 CLOSED

不配置JTAConfig 是否正常呢

from fastdep.

看这个错误，貌似和全局事物无关

from fastdep.

@louislivi 不配置JTAConfig也不正常，我又做了另外一个测试:不引用fastdep-datasource,单独引用druid-spring-boot-starter、mybatis-spring-boot-starter、spring-boot-starter-jta-atomikos，就不存在连接泄露的问题，请问一下我的fastdep配置有问题吗？

        <groupId>com.alibaba</groupId>
        <artifactId>druid-spring-boot-starter</artifactId>
        <version>1.1.21</version>
    </dependency>
    <dependency>
        <groupId>org.mybatis.spring.boot</groupId>
        <artifactId>mybatis-spring-boot-starter</artifactId>
        <version>1.3.2</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-jta-atomikos</artifactId>
        <version>2.4.2</version>
    </dependency>

from fastdep.

@WangHanHong 这个看着应该是removeAbandoned 的问题

from fastdep.

removeAbandoned配置会引发这个问题，建议查看相关问题进行解决。

from fastdep.

@louislivi removeAbandond是打开的，他的作用是强制回收连接，但是我的代码就是一个简单的查询 @RequestMapping("getModel") public String getModel(String id) { List<MsgModel> models = modelMapper.listMsgModelByCondition(new HashMap<String, Object>() {{ put("id", id); }}); return models.get(0).getContent(); }不存在慢查询的问题，而且我把removeAbandonedTimeout设成了1800s，sql的查询时间在这个范围内，我的业务代码应该不会造成连接泄露，我打开druid的监控显示 始终有6个连接未释放

from fastdep.

removeAbandoned是连接池的高级功能，理论上这中配置不应该出现在实际的生产环境，因为有时应用程序执行长事务，可能这种情况下，会被连接池误回收，该种配置一般在程序测试阶段，为了定位连接泄漏的具体代码位置，被开启。生产环境中连接的关闭应该靠程序自己保证。

from fastdep.

问题的原因不明，也有可能是兼容问题，可以查看源码中进行确认，但是fastdep做到的仅仅是注入bean的操作，并未针对druid或者其他依赖相关配置以及源码修改。

from fastdep.