FAQ

Q: Why doesn't HikariCP support Java 6 (or Java 5)?

A: HikariCP achieves its performance by taking advantage of technologies only available in Java 7. While we did experiment with a Java 6 version, the performance was an order of magnitude slower. HikariCP is designed for deployments where every millisecond counts, and under those conditions it is hard to imagine anyone trying to achieve that on JVM technology that is over 7 years old.

Q: I am getting a "com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure" exception logged in the isConnectionAlive() method of HikariPool in my logs, what is happening?

A: Configure your HikariCP idleTimeout and maxLifeTime settings to be one minute less than the wait_timeout of MySQL. See this article about setting MySQL timeout values.

Q: I am getting strange transaction isolation behavior after changing it, what is happening?

A: Always use the JDBC Connection.setTransactionIsolation() method rather than executing SQL to change the isolation level. HikariCP must reset the isolation level for connections returned to the pool, but only does so if it detects that the isolation level has changed. Using SQL rather than the JDBC API to manipulate the isolation level prevents HikariCP from being able to detect the change, and therefore it will not reset the isolation level. This can cause the isolation level set by one consumer to "bleed" over to another consumer of the pool.

Q: I benchmarked Other Connection Pool X and HikariCP is coming out slower, what is happening?

A: Make sure you are comparing apples-to-apples. While HikariCP strives to be high-performing it also strives to be high-reliability. Many other pools' default settings are geared for performance over reliability. Additionally, unless you configure the underlying JDBC driver correctly, you are likely to miss out on performance. For example, other pools include a prepared statement cache of their own, while HikariCP relies on the caching ability of the underlying JDBC driver. Unless you enable this feature in the driver, you are losing performance. As an example, see the MySQL Configuration Tips.

Not to pick on any one pool, but this topic came up in the forums Re: C3P0 vs. HikariCP. By default C3P0 errs on the side of performance by not testing connections before handing them to you. Instead they are checked by a background thread. While this will certainly boost performance, if your backend database is restarted or a network interruption occurs, your application could be handed bad connections for as long as it takes the background thread to test them all (30 seconds by default). For an apples-to-apples comparison, you would need to set the C3P0 testConnectionOnCheckout property to true.

Q: How to I properly enable PreparedStatement caching for PostgreSQL?

A: Because HikariCP does not implement statement caching, consider this tip a freebie. Set the "prepare threshold" for PostgreSQL like this:

...
hikari.dataSourceClassName=org.postgresql.ds.PGSimpleDataSource
hikari.dataSource.prepareThreshold=1
...