Static analysis limits regarding runtime connection pool exhaustion

Answer

Qodana’s static analysis can flag structural resource leaks (e.g., a JDBC Connection opened but never closed on some execution path) but it cannot observe the live state of a connection pool under load. Therefore it cannot directly predict pool exhaustion caused by traffic spikes, concurrency bottlenecks, or mis‑sized pool settings.

Confirmed facts

• Static analyzers like Qodana detect only code‑level leaks via data‑flow analysis; runtime pool exhaustion is a load‑dependent phenomenon invisible to static inspection.
• Qodana’s JVM resource‑leak inspections recognize try‑with‑resources and explicit close() calls, so properly scoped code is not flagged.
• For connections obtained from a DI‑managed DataSource (Spring, CDi, etc.), the inspection cannot prove ownership semantics; it may either flag the getConnection() call as a potential leak or stay silent, depending on configuration.
• There is no out‑of‑the‑box inspection that proves an architectural anti‑pattern “will cause pool exhaustion”.

Likely explanation

Because Qodana runs in CI/CD without access to live metrics, it cannot see:

1. Current pool size, idle/active counts, or wait times.
2. Burst traffic that temporarily exceeds the configured maximum connections.
3. Thread‑local or async code that holds a connection longer than expected.

What it can approximate are structural patterns that increase the risk of exhaustion, such as:

• Calling DataSource.getConnection() outside a try‑with‑resources block.
• Storing a connection in a field, static variable, or thread‑local and not returning it.
• Passing a connection across asynchronous boundaries (e.g., CompletableFuture) without explicit close.

Steps to mitigate the gap

1. Enable and verify resource‑leak inspections in your qodana.yaml (or via the UI). Ensure the JVM inspection IDs for jdbc resources are active.
2. Add a custom Detekt rule (or Qodana‑compatible inspection) that flags:
1. getConnection() calls not wrapped in try‑with‑resources or a matching close() on all paths.
2. Connections assigned to class fields or statics.
3. Connections returned from a method but not closed before the method returns.
3. Treat DI‑managed connections as reviewed items: if your framework returns a pooled connection that the framework closes, add a suppression or custom rule that recognizes the framework’s DataSource bean (e.g., Spring’s @Autowired DataSource) as safe.
4. Complement with runtime observability:
1. Enable pool metrics (HikariCP, Tomcat JDBC, etc.) and expose them via Prometheus/JMX.
2. Set alerts on high checkout latency, idle timeout, or exhausted pool.
3. Correlate spikes with deployment changes or load tests.
5. Validate on a test case: create a minimal class with (1) a leaked connection, (2) a proper try‑with‑resources block, and (3) a Spring‑injected repository method; run Qodana and confirm which are flagged.

Missing diagnostic detail

To refine the recommendation, please confirm which dependency‑injection framework (if any) you use for obtaining DataSource connections (e.g., Spring, CDI, Guice) and the exact Qodana version you run. This determines whether a specific suppression or custom rule is needed for DI‑managed connections.