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: 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
...