Other lesson learned about HikariCP has been when we enabled setLeakDetectionThreshold working on a service request was receiving the following error message: 20:21:42.089 [AppExample-ConnectionPooling housekeeper] WARN com.zaxxer.hikari.pool.ProxyLeakTask – Connection leak detection triggered for ConnectionID:1 ClientConnectionId: b9b5344d-f970-XXX-xxxxxxxxxx on thread main, stack trace follows java.lang.Exception: Apparent connection leak detected at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:100)

The learned lesson here was, that, in the context of connection leak detection in HikariCP, it is not only the closing of the connection that matters but also the execution of the query and the handling of associated resources. A connection leak occurs when a connection is acquired from the pool but not returned, which can include not properly closing ResultSet and PreparedStatement objects as well as the connection itself. In this case, I found a query that took more than that this setting.

Considerations for Leak Detection

1. Query Execution:

If a query takes a long time to execute, it can appear as a leak if the execution time exceeds the configured leak detection threshold (leak-detection-threshold).
It is important to optimize queries to ensure they complete in a reasonable time frame.

2. Closing the Connection:

Ensuring the connection is closed after its use is complete, regardless of whether the query was successful or failed.

​Microsoft Tech Community – Latest Blogs –Read More