Frequently Anticipated Questions

Why isn't there support for connection checking on releasing a connection or right before obtaining one?

We do not see much of a use case here. There is simply no guarantee that testing a connection right before giving it out to the callee will work for the connection might fail at the very next moment. This means that your application will still have to deal with failure so that begs the question: "why bother?" together with "why slow things down for the normal case?". The same applies for testing in a connection on releasing it.

 

...but is there support for checking the health of a connection?

Yes. What happens is that when an exception comes up, the first code to handle that resides in BoneCP (because the connection returned is really a ConnectionHandle - a wrapper around the Connection class). The code will check the SQL state code as per the JDBC spec and take appropriate action which usually means one of the following:

How do you test a JDBC connection?

There are several mechanisms but the one BoneCP uses are:

What happens if the connections on a partition run out?

An attempt is made to steal connections from the rest of the partitions. When the connection is released, that connection goes back in the original partition so that the partitions remain balanced. If no connections are available, the library blocks waiting until a connection is free on the thread's partition (BoneCP never spin-locks).

Will the connection pool close off statements/preparedStatements/callableStatements when I close/release the connection?

As of v0.6.4 onwards, no, though it will issue warnings if you forget to do so (with the right config settings enabled). This ensures that during development you can fix all the relevant bugs whilst not affecting general performance. However the JDBC spec is very unclear on the expected behaviour of what should happen when a connection is closed so always make sure to close off the statements you are done with manually yourself anyway. Consider how your application would behave if in future you need to change to a different connection pool for example.

What happens if the connection pool becomes exhausted of connections?

Unlike some other connection pools, BoneCP will simply block until there's a free connection. Typically, this is a result of an application not freeing a connection properly after use or using up more connections than are available. The possible solutions include increasing the pool size or decreasing the connection requests via caching (Spring's LazyDataSource really helps here!). If you care about doing something else in the meantime, try getAsyncConnection() to obtain a Future. You may set the JDBC timeout to prevent queries from taking a very long time to execute.

For which database will BoneCP work?

At present, BoneCP has been tested successfully on HSQLDB and MySQL with no reports of other problems on any other database (so far). BoneCP relies on JDBC drivers being present in your classpath that are usually loaded via a call similar to: Class.forName("org.hsqldb.jdbcDriver"); therefore the connection pool doesn't really care which database you use (be it MySQL, Postgres, Sybase, Oracle, Microsoft SQL, DB2, etc).

Why do I get class not found error: java.lang.NoClassDefFoundError: com/google/common/collect/ImmutableSet ?

You're missing the Google Collections library in your classpath, also available here. If you are using maven as described in the download section, this library should have been downloaded for you automatically and added to your classpath.