Hi 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. Regards, Thomas Jahnsen
--
[Message sent by forum member 'tjahnsen']
View Post: http://forums.java.net/node/891191