Connection leak in Spring transaction

本文介绍了一个关于Spring事务管理中出现的数据库连接泄漏问题,并详细分析了解决方案。作者最初使用了TransactionTemplate进行编程式事务管理,但在实践中遇到了连接泄漏。经过排查,发现是由于直接获取DataSource连接并使用而未关闭导致。最终通过手动释放连接解决了问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最近弄个http服务,传入xml,然后可以执行xml中定义的sql,并且在事务中执行。

本来用了spring的TransactionTemplate写的编程式事务,后来使用下来发现有数据库连接泄漏。。

百思不得其解,居然怀疑了spring的这种事务支持方式是不是会有点问题。于是改成了自己比较熟悉的org.springframework.transaction.interceptor.TransactionProxyFactoryBean

来代理需要有事务支持的类,确保应该没问题。。结果测试下来还是有泄漏。。没调用一次就少一个连接。。。

 

google了好一会,看到有说spring事务连接泄漏的文章,讲到spring所管理的连接是在当前线程中的

 

引用IBM developerWorks里面找到的一段

 

Spring 事务管理高级应用难点剖析: 第 3 部分 写道
Spring DAO 对所有支持的数据访问技术框架都使用模板化技术进行了薄层的封装。只要您的程序都使用 Spring DAO 模板(如 JdbcTemplate、HibernateTemplate 等)进行数据访问,一定不会存在数据连接泄漏的问题 ―― 这是 Spring 给予我们郑重的承诺!因此,我们无需关注数据连接(Connection)及其衍生品(Hibernate 的 Session 等)的获取和释放的操作,模板类已经通过其内部流程替我们完成了,且对开发者是透明的。
但是由于集成第三方产品,整合遗产代码等原因,可能需要直接访问数据源或直接获取数据连接及其衍生品。这时,如果使用不当,就可能在无意中创造出一个魔鬼般的连接泄漏问题
我们知道:当 Spring 事务方法运行时,就产生一个事务上下文,该上下文在本事务执行线程中针对同一个数据源绑定了一个唯一的数据连接(或其衍生品),所有被该事务上下文传播的方法都共享这个数据连接。这个数据连接从数据源获取及返回给数据源都在 Spring 掌控之中,不会发生问题。如果在需要数据连接时,能够获取这个被 Spring 管控的数据连接,则使用者可以放心使用,无需关注连接释放的问题。

 

 

于是我看了下自己代码。。。发现在刚调用进来时候,我会有个判断当前数据库类型的操作,是为了如果是oracle,需要alter session一下,问题就出在这个判断当前数据库类型的地方:

if(jt.getDataSource().getConnection().getMetaData().getDriverName().toLowerCase().indexOf("oracle")>=0){

这里从JdbcTemplate里面获取一个数据库的Connection,而这个connection不在spring的管理范围内。。

 

所以这里的这个connection需要手动释放,这样就没有问题了。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值