码迷,mamicode.com
首页 > 其他好文 > 详细

较为简单的连接池泄露 解决思路

时间:2016-05-08 06:54:22      阅读:176      评论:0      收藏:0      [点我收藏+]

标签:连接池 泄露

由于是金融公司,所以不便透露代码和系统名称。

背景描述

1) A系统的UAT环境会推送数据到B系统。


技术分享


2)由于系统间没有采用消息中间件进行解耦,B系统的连接池出现泄露导致A系统功能也受到影响。

3)生产环境没有出现问题。

4)服务器为IBM外包管理,无权查看JVM的DUMP,无权登录到服务器机器。

5)连接池并非马上全部泄露,而是渐渐的被吃掉。


采用技术框架:

    SEAM+SPRING+HIBERNATE

    数据库ORACLE RAC



诊断:

由于生产环境并没有发现问题,大概率可以断定是由于数据问题导致。从DBE团队提供的一份数据来看,几乎所有的连接SESSION都是执行了某一个同样的SQL(Hibernate生成)后,卡死。


1)追踪到SQL,从SQL追踪到Hibernate,然后找到了相应的代码。(运气较好,此段SQL只出现在了我们一处代码上面,很容易就锁定了泄露嫌疑区域)


技术分享


由于所有的SESSION卡在A,所以断定应该是检查数据的过程出现问题。于是进行查看。

锁定原因:

红色区块检查数据的代码中,抛出了一个运行时的异常。

很可惜,外部的手动管理的事务压根没有做try catch进行回滚事务操作。异常被线程池捕获处理,连接并没有返回到连接池。


最后还是要澄清一下,这代码不是我写的。。。。。


在无法实时查看JVM的情况下,DBE团队提供的数据起了很大的帮助。

追踪泄露了的SESSION最后执行的SQL,也是一个非常好的起点。



本文出自 “Tech Doc” 博客,谢绝转载!

较为简单的连接池泄露 解决思路

标签:连接池 泄露

原文地址:http://mindoverflow.blog.51cto.com/11468509/1771123

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!