I wonder if the timeout route would not be considered a bit aggressive. You would literally fail instead of being slow.

Yes, we only could do that when providing options for timeout and pool size so a user can increase the settings if required.

BTW do we keep the same connection for a whole batch of grid dialect operations? It's a bit less resource friendly but I think the database will be in a better and more consistent state as you can push all your relevant changes (for a given flush). It's not as great as one connection per transaction but that one would keep the http connections under-utilised.

There are no guarantees which connections are used and whether it's the same one for the operations from one session/TX/batch of work. The connection lease happens under the covers (the RESTEasy client uses the Apache HTTP client which gets a connection from the configured pool). Not sure whether we could trick RESTEasy into using a connection which we obtain ourselves for a flush cycle and pass into the client. It might be possible to plug in a custom pool implementation which allows to demarcate a unit of work and leases one and the same connection for that thread as long as that demarcation is active.

I like your idea of using getStats(). It does involve a lock acquisition by the pool but so does most operations. We could count and aggregate the ratio of time where stats.getAvailable() is 0 when we are about to ask for a connection. Thoughts?

That might be a viable way. We could log on INFO or WARNING depending on whether the ratio succeeds a certain threshold.