XX系统在生产环境使用一定时间后表现出用户不能登录，后台tomcat日志报如下错：
2008-08-14 12:31:35,029 [org.hibernate.util.JDBCExceptionReporter]-[WARN] SQL Error: 0, SQLState: null
2008-08-14 12:31:35,029 [org.hibernate.util.JDBCExceptionReporter]-[ERROR] Cannot get a connection, pool exhausted
2008-08-14 12:31:35,029 [org.hibernate.util.JDBCExceptionReporter]-[WARN] SQL Error: 0, SQLState: null
2008-08-14 12:31:35,029 [org.hibernate.util.JDBCExceptionReporter]-[ERROR] Cannot get a connection, pool exhausted
显然是连接池满了，驻地工程师重启之后就可以正常使用了。因为我们的tomcat连接池的配置连接
参数好像很大，所以应该肯定是程序出
问题了。后来在测试那也出现了同样的问题，因为测试的人比较多，所以那两天基本上一两个小时连接池就满了，当时只能一次一次的重启tomcat。
因为XX系统之前已经修改过一次因为
代码的
错误而导致的
数据库连接没有释放的问题，所以这一次的问题比较不好定位，不能知道是哪些操作的连接池没有释放。
后来由zhxy提供了如下的查看当前数据库（
sybase）哪些连接没有被释放的脚本，其中的ip为tomcat的发布地址（因为数据库连接都是由tomcat发起）：
declare cur_spid cursor
for
select spid from sysprocesses where ipaddr='172.16.7.8'
go
declare @spid Integer
open cur_spid
fetch cur_spid into @spid
while @@sqlstatus=0
begin
print '%1!' , @spid
dbcc traceon(3604)
dbcc sqltext(@spid )
fetch cur_spid into @spid
end
close cur_spid
使用该脚本只能之后，执行结果都是打印出大量类似的下面的三行：
184
DBCC execution completed. If DBCC printed error messages, contact a user with System Administrator (SA) role.
SQL Text: set CHAINED off
直接使用上面的脚本打印的结果是当前占用数据库连接池的spid（第一行），以及连接正在执行的sql（第三行）。
后来发现每登录一次审判系统，使用上面的脚本执行结果就会有一个连接没有被释放（一般连接会在一段时间之后释放），除非是重启tomcat否则一直占用。
跟踪
登陆代码发现有如下的写法（调用存储过程）：
Session session = this.getSession();
Transaction tx = session.beginTransaction();
Connection con = session.connection();
try {
//……
CallableStatement cstmt = con.prepareCall("{call K_TJ..PR_GET_AjCount(?,?,?,?,?,?,?,?,?,?,?,?) }");
//……
ResultSet resultSet = cstmt.executeQuery();
tx.commit();
if (resultSet.next())
ajCount = resultSet.getInt(1);
resultSet.close();
} catch (Exception e) {
tx.rollback();
e.printStackTrace();
return 0;
} finally{
try
{
con.close();
}
catch (SQLException e)
{
e.printStackTrace();
}
}
这里有几个问题，一是把hibernate和connection的用法使用混乱了；二是使用session获取的连接不需要自己关闭，应该关闭session（一个session对应一个connection），这里刚好用使用反了。
后来试着把con.close()改成session.close()问题就没有了，后来经zhangjy提醒，如果是使用spring提供的getSession()获取的连接，最好是使用releaseSession()方法进行释放。引用原话“release不一定是关闭连接，就像连接池的连接一样。release只是放回池中，你要关闭了 就不能放回池中了 而且 直接close可能会抛异常，release不会抛异常 因为里边有对
环境的判断”，把con.close()改成releaseSession()问题也解决了。
但是我们的项目中使用了spring，对存储过程调用最好是使用jdbcTemplate。退一步如果要获取一个connection，最好能使用
Summer提供的jdbcDao获取，即jdbcdao.getDataSource().getConnection()，当然这样的连接完全就需要自己手工关闭了。
最后搜了一下代码，把程序中如上调用存储过程的地方全部改为使用jdbcTemplate问题解决。最终代码如下:
getJdbcDAO().getJdbcTemplate().execute(
"{call K_TJ..PR_GET_AjCount(?,?,?,?,?,?,?,?,?,?,?,?) }",
new CallableStatementCallback() {
public Object doInCallableStatement(CallableStatement cstmt)
throws SQLException, DataAccessException {
//……
ResultSet resultSet = cstmt.executeQuery();
if (resultSet.next())
return new Integer(resultSet.getInt(1));
// ……
});
连接池的问题解决。
posted on 2008-08-30 15:03
岁月如歌 阅读(7150)
评论(2) 编辑 收藏 所属分类:
java