JDBC connection leak reclaim and long-running operations
I have run against a problem with a server application I have on GlassFish. It gets a JDBC Connection from a DataSource that has been set up in GlassFish with leak detection and leak reclaim. It would start a very long operation, but then GlassFish would mark the connection as leaked and reclaim it, and the operation would fail in the middle with a "connection has been closed" SQLException.
After reading up on the leak detection in GlassFish, I find out the period given is between DataSource.getConnection() and Connection.close(), and not what I had expected; the period since last communication.
A proper leak is when the method using the Connection exits without closing, leaving the Connection dangling. When this happens, I expect there is no more data or communication passing on it.
In my operation, I perform a "SELECT * FROM table" with an updateable ResultSet; for each row, I read some columns, performs a Web Service with the data (searches for the coordinate of an address), and saves the coordinate in another column. There are plenty of ResultSet.updateObject calls and a ResultSet.updateRow for each row.
Is it feasible for the connection pool to monitor time since the last operation instead of the start of the connection lease? Why isn't it so today? It would seem more useful for actual leaks and for not eating up long-running operations.
There are several ways for me to solve my problem; turn off reclaim, or run in batches of (with OFFSET and LIMIT). As a quick-fix I have turned off reclaim and increased the period so fewer operations will (incorrectly) report a leak.