First off, thank you for a such an awesome library! We switched from C3P0 because we didn't like the way threads would get a connection from a pool based on luck rather than the order they were in.
Anyway, so we were using 0.7.1. Everything was fine until we needed to have the locking bug fix of 0.8.0 (When release of the lock wasn't in a finally block). We switched the library version and all of a sudden out test are failing all over the place. What we are finding is that the connection tracking is classing checked out connections as needing to be closed.
WARN [com.google.common.base.internal.Finalizer] c.jolbox.bonecp.ConnectionPartition - BoneCP detected an unclosed connection and will now attempt to close it for you. You should be closing this connection in your application - enable connectionWatch for additional debugging assistance.
(n.b. I have tried enabling the connectionWatch but I don't see anything extra being logged except for the 'this is a debug only setting' message)
This then leads to the transaction failing because the connection has been closed. What is interesting it takes a while for it to happen,
this varies depending on the amount of the Threads we have in the test. But it will always happen a set amount of usages.
We are using Spring 3.0.6 and using the @Transactional transaction demarcation.
The other interesting thing that occurs is we use the following
- Code: Select all
SimpleJdbcTestUtils.executeSqlScript(new SimpleJdbcTemplate(ourTemplate), new ClassPathResource("ourSetupSQL.sql"), false);
(n.b. We have 2 datasources to different to DB's.)
at the the start of our test and when the connection tracking kicks in and warns about unclosed connections it also says that there is an unclosed connection associated with the datasource used with the SimpleJdbcTestUtil. How can this be I stepped through the code and saw it close it.
After looking through the config I see it is noted that if we were using Spring to managed our connections, which I believe is what we are doing with the Spring TX'ing, then we can turn off the tracking. But what concerns me is the change between the 2 versions of BoneCP that would suddenly cause us to have this issue. Is 0.8.0 not really production ready? I note it is alpha in the name, if it isn't I may just back port the change that we want for the locking to 0.7.1-RELEASE.
Any thoughts would be much appreciated
James
