Question

I am using JTDS to connect to MS-SQL 2005. I am using c3p0 as the DB Connection pool, configured with Spring.

I am randomly getting an SQLException: Invalid state, the ResultSet object is closed in a Groovy script in which I have passed a reference to the connection pool. The script is executed by a timer every so often. By random, I mean that the script works perfectly 99% of the time, but when it fails, it will do so a couple of times, then go back to working correctly again, picking up where it left off. All of the critical work is done in a transaction, pulling off of a Message Queue.

Logic below:

    //passed into the groovy context
    DataSource source = source;
    Connection conn = source.getConnection();

    ...
    //Have to omit proprietary DB stuff... sorry...
    PreparedStatement fooStatement = conn.prepareStatement("INSERT INTO foo (x,y,z) VALUES (?,?,?) select SCOPE_IDENTITY();");        
    ResultSet identRes = fooStatement.executeQuery();

    //This is where the execption is thrown.
    identRes.next();

    ...

    try{
         log.info("Returning SQL connection.");
         conn.close();
    }catch(Exception ex){}

There is a separate timer thread that runs a similar groovy script, in which we have not seen this issue. That script uses similar calls to get the connection, and close it.

Originally, we thought that the second script may have been grabbing the same connection off the pool, finishing first, then closing the connection. But c3p0’s documentation says that calling conn.close() should simply return it to the pool.

Has anyone else seen this, or am I missing something big here?

Thanks.

Answer 1

We solved this… C3P0 was configured to drop connections that were checked out longer than 30 seconds, we did this to prevent dead-lock in the database (we don’t control the tuning). One of the transactions was taking horridly long to complete, and C3P0 was dropping the connection, resulting in the ResultSet Closed error. Surprisingly, however, C3P0 was not logging the incident, so we didnt see this in the application’s logs.