Currently, getConnection blocks current thread if a connection is not immediately available. It would be great to have an asynchronous version of this function that would accept a callback, or return a future. This callback/future would be completed when connection is available, thus unblocking a thread to do some other useful work, while waiting in a queue to access a database.
Such queue should be bound (have a limit on the number of items in the queue) and exception would be thrown if queue is full, thus allowing for controlled back-pressure propagation.
Oracle and the JSR community are currently working on the specification for a standard async JDBC API. When the specification becomes more solid, HikariCP will provide an implementation.
I was hoping to use it with Kotlin coroutines, and JSR won't be widely implemented, and thus generate demand, for at least several years…
It's in preview at the moment https://blogs.oracle.com/java/jdbc-next%3a-a-new-asynchronous-api-for-connecting-to-a-database
This is a big problem for anyone using Vert.x and event loops since it can lead to deadlocks.
@brettwooldridge what are your thoughts on http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2019-September/000529.html?
Most helpful comment
I was hoping to use it with Kotlin coroutines, and JSR won't be widely implemented, and thus generate demand, for at least several years…