> Just to make things clear, this is not a deadlock, but a saturated connection pool and high contention

When this happens:
Thread A holds a lock on a shared instance of PooledOptimizer and is waiting on a connection from the connection pool
Threads B-N hold all of the connections in the pool, and are stuck waiting on the lock that Thread A is holding to be released

I guess it's not a database deadlock, but it's definitely a deadlock. Unfortunately there is no amount of connections in the pool that could prevent this from happening.