数据库连接池满的问题

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));
                        // ……
                });

连接池的问题解决。