We’ve identified a scenario where the system is unable to retrieve any new database connections from the pool where all of the connections are acquired but in an IDLE state. This means that something is holding on to them, but is not actively using them for any queries.

While investigating the system through a heap dump, we found that the connections were owned by Spring’s transaction manager in the context of some provisiond scan threads.

Here is a stack trace from one of the threads that shows the problem:

Here we see the thread traversed through Spring’s transaction management, and is subsequently trying to obtain a new connection from the pool. In this case, one connection is already acquired by the transaction, leaving us susceptible to a deadlock.

The problem relates to the use of the @Transactional annotation on the JdbcFilterDao class: . Since we do not use Hibernate/Spring in this class, and we instead interact with the pool and JDBC directly, we do not need AOP or Spring’s transaction management.

This deadlock is more likely to be encountered on systems using the “SNMP profiles” feature in conjunction with a higher number of provisiond threads.