I thought jDBI was supposed to handle closing JDBC connections when using withHandle...

[Stephen Connolly]

Hi!

Getting a lot of stack traces like this in my logs... and MySQL is running out of connections and bringing the app to its knees...

org.apache.tomcat.dbcp.dbcp.AbandonedTrace$AbandonedObjectException: DBCP object created 2013-03-01 06:00:51 by the following code was never closed:

at org.apache.tomcat.dbcp.dbcp.AbandonedTrace.setStackTrace(AbandonedTrace.java:139)

at org.apache.tomcat.dbcp.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool.java:81)

at org.apache.tomcat.dbcp.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106)

at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)

at org.skife.jdbi.v2.DataSourceConnectionFactory.openConnection(DataSourceConnectionFactory.java:36)

at org.skife.jdbi.v2.DBI.open(DBI.java:207)

at org.skife.jdbi.v2.DBI.withHandle(DBI.java:272)

        at ... my code ...

jDBI version 2.45

My understanding is that withHandle should always close a connection if it opens a connection, and my reading of the code is the same... so I am at a loss to understand how the DBCP thinks its loosing connections...

Any thoughts?

Oh and jDBI is otherwise a great library

-Stephen

[Brian McCallister]

It should, it has been for years. Bizarre. I am sick, but will verify the code as soon as I get a chance. Does *anything* else open connections too?

--
You received this message because you are subscribed to the Google Groups "jDBI" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jdbi+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Stephen Connolly]

I will double check, but I did a purge of non jDBI code... I'll triple check that the 2/3 places where I use openHandle() to ensure I close it again in a finally just in case... But I suspect I was careful

Sent from my iPhone

[Stephen Connolly]

Double checked...

99% of the code is one of dbi.withHandle(...), dbi.inTransaction(...) and dbi.onDemand(daoClass)

There are 3 cases where I didn't want to make variables final, so use Handle h = dbi.open(); try { ... } finally { h.close(); }

There is one use without jDBI, which is in the ServletContextListener where I have the code that upgrades the DB schema if necessary and that code is rock solid and closes its connection correctly.

The only other thing I can think is that Tomcat's pooling may be "leaking" the connection when testing before handing over to jDBI

[Stephen Connolly]

Hmmmm we seem to be having DB connections taking a long long time to finish their write operations... so hopefully we can confirm that it is just the write operations hanging, DBCP deciding they have not been used in > 5 minutes and falsely accusing the connection of leaking. All the leak warnings are on INSERT/UPDATE/DELETE SQL queries which would support this.

[Stephen Connolly]

Confirmed. It was a write lock on the DB and connections being held while the operations were blocked.... sorry for the noise