FAQ

Q: PostgreSQL throws an exception stating setQueryTimeout(int) is not yet implemented, how do I fix it?

A: Don't use the connectionTestQuery, instead allow HikariCP to use the Connection.isValid() method (the default).

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 do I properly shutdown the HikariCP DataSource?

A: Shutting down the DataSource is especially important in web application containers where applications can be hot-deployed. Call the shutdown() or close() method on the HikariDataSource instance. You can typically configure Spring or other IOC containers to specify a "destroy" method.

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 highly-reliabile. 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: The PostgreSQL JDBC driver from the PostgreSQL project does not support PreparedStatement caching. We recommend the new (but stable) pgjdbc-ng driver for using PostgreSQL.

Q: How to I encrypt database passwords with HikariCP?

A: HikarCP does not support built-in decryption/encryption of passwords. We recommend using the jasypt library. It additionally includes many useful Spring components including decrypting versions of:

• PropertyPlaceholderConfigurer
• PropertyOverrideConfigurer
• PreferencesPlaceholderConfigurer