Continuous Java heap growth after a Microsoft JDBC Driver upgrade needs a controlled comparison. Reproduce the same workload with the old and new driver, close every JDBC resource deterministically, and inspect which driver objects remain reachable.
Last updated: October 31, 2026.
String sql = "{call dbo.WriteEvent(?, ?)}";
try (Connection connection = dataSource.getConnection();
CallableStatement statement = connection.prepareCall(sql)) {
statement.setLong(1, eventId);
statement.setString(2, payload);
statement.execute();
}Try-with-resources closes the statement before returning the logical connection to the pool. Use the same pattern for every ResultSet, Statement, and Connection, including exception paths. Confirm the pool returns to its normal active-connection baseline after the test completes and traffic becomes idle.
Separate an application leak from a driver regression
Run a fixed-duration load test with identical JVM, pool, database, and traffic settings. Change only the JDBC driver version. Record heap after garbage collection, active and idle pool counts, statement creation rate, and the number of retained SQLServerCallableStatement or prepared-statement objects.
Microsoft’s guide to closing JDBC objects says statements and result sets should be explicitly closed when no longer needed. A heap dump and dominator tree can then show whether application references, the connection pool, or a driver cache retains them. Take samples at consistent intervals so normal cache warm-up is not mistaken for unbounded growth.
Test statement pooling independently
The driver’s connection properties document that statementPoolingCacheSize enables a per-connection prepared-statement cache when statement pooling is enabled. Repeat the comparison with pooling disabled or a smaller cache, while keeping the workload unchanged.
If only one driver release shows unbounded growth, preserve the minimal reproducer, heap evidence, configuration, and version matrix for the driver maintainers. Use a tested unaffected or fixed release rather than simply increasing the heap. Continue with configuring JDBC pool timeouts, testing JDBC batch inserts, and diagnosing SQL Server client timeouts.
