-
Notifications
You must be signed in to change notification settings - Fork 3k
Pool Analysis
This page contains a critical analysis of popular JDBC connection pools.
Let us agree here today to adopt among ourselves a simple and unwritten rule.
We will not rise to criticize someone else's idea unless we are prepared to
offer an alternative idea of our own.
- Marco Rubio
The biggest single issue with BoneCP is the inability to configure the pool to test connections at the time of getConnection(). Every other pool here can be configured in that way. This is a sacrifice of reliability for speed.
A connection pool should clear SQL warnings via Connection.clearWarnings() either when the Connection is returned to the pool or before it is taken from the pool. BoneCP does not do this.
When the connection is configured for autocommit=false a connection pool should perform the test query or isValid() test within its own transaction, otherwise the query becomes part of the user's transaction. The same is true for the "initSQL" that can be run on a Connection when it is created. BoneCP does not encapsulate the Connection test or the initSQL in its own transaction.
While not well known currently, Vibur is actually one of the better pools out there. But here is where we think Vibur gets it wrong:
The JDBC contract specifies that when a Connection is closed, any open Statements that have not been closed yet should automatically be closed, otherwise a resource leak on the database server-side could occur. Only in the case of cached PreparedStatements or CallableStatement does Vibur perform such resource cleanup. Even when caching is enabled ordinary Statement objects are not tracked for cleanup. When caching is disabled no Statements are tracked at all.
When the connection is configured for autocommit=false a connection pool should perform a rollback() operation either when the Connection is returned to the pool or before it is taken from the pool. Unless this is performed, transactions can "bleed" over from one use of the Connection to the next. Vibur does not do this.
When the connection is configured for autocommit=false a connection pool should perform the test query or isValid() test within its own transaction, otherwise the query becomes part of the user's transaction. Vibur does not encapsulate the test in its own transaction.
A connection pool should clear SQL warnings via Connection.clearWarnings() either when the Connection is returned to the pool or before it is taken from the pool. Vibur does not do this.
Vibur, like HikariCP and BoneCP, can detect when a SQLException indicates that a Connection has been severed. This is a good thing, but there are two issues. Vibur's list of detected SQL error codes is more limited than either HikariCP or BoneCP. Surprisingly, when Vibur detects that an exception has occurred on one connection, it ejects all connections from the pool, not just the connection that encountered the exception. Maybe this is "pro-active" but it is also likely to create a stampede of new connections to the database. The jury is still out on whether this is a good idea or not, we tend to lean toward not.