Vaadin Grid DataProvider and intermittent JDBC connection pool exhaustion

Answer to the Question

In Vaadin Flow, a CallbackDataProvider obtains a JDBC connection at the start of fetchFromBackEnd and keeps it open until the method returns. If the method contains blocking or long‑running work, the connection stays checked out, increasing the chance of exhausting the pool under concurrent Grid requests.

By contrast, a SpringDataProvider delegates to Spring’s @Transactional infrastructure. The transaction begins when the DataProvider calls the repository, and the transaction manager automatically closes the JDBC connection as soon as the repository method completes, even if the Grid callback itself takes longer.

Confirmed Facts

• CallbackDataProvider requires explicit closing of Connection, Statement, and ResultSet objects.
• SpringDataProvider relies on Spring’s transaction boundaries, which close the connection automatically.
• Connection exhaustion typically occurs when long‑running queries or blocking calls are executed inside the DataProvider callback.
• HikariCP (common pool) can be configured with leakDetectionThreshold to surface unclosed connections.

Likely Explanation

Because the UI thread in Vaadin synchronizes Grid updates, developers sometimes perform additional business logic inside fetchFromBackEnd. In a custom provider, this logic may inadvertently keep the JDBC connection open. SpringDataProvider’s automatic transaction demarcation reduces this risk, but only if the repository method remains lightweight and does not spawn additional threads that outlive the transaction.

Recommended Pattern for High‑Concurrency

1. Prefer SpringDataProvider when your application already uses Spring Data. It handles connection acquisition and release automatically.
2. If you must use a custom CallbackDataProvider, wrap database access in try-with-resources blocks:

   try (Connection conn = dataSource.getConnection();
        PreparedStatement ps = conn.prepareStatement(sql)) {
       try (ResultSet rs = ps.executeQuery()) {
           // build items
       }
   }
   

3. Move heavy business logic or remote calls outside the DataProvider. Use a service layer that returns plain DTOs.
4. Enable HikariCP leak detection:

   spring.datasource.hikari.leakDetectionThreshold=30000  // 30 seconds
   

5. Tune the pool size to the expected maximum concurrent UI requests. For example, if you anticipate 200 concurrent Grid fetches, set maximumPoolSize to 250 to allow headroom.
6. Monitor pool metrics (activeConnections, idleConnections) during load tests. If activeConnections approaches maximumPoolSize, increase the pool or reduce query latency.

One Diagnostic Detail That Can Alter the Recommendation

What is the current maximumPoolSize configured in your JDBC pool? If it is already close to the number of concurrent UI threads, even a well‑behaved SpringDataProvider may experience exhaustion.

Conclusion

For most Vaadin applications, using SpringDataProvider with Spring’s transaction management is the safest approach to prevent JDBC connection leaks under high concurrency. When a custom provider is unavoidable, enforce strict resource cleanup and keep the callback focused solely on data retrieval.