I wonder if the timeout route would not be considered a bit aggressive. You would literally fail instead of being slow.
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.

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?