On Fri, Oct 10, 2003 at 11:21:45AM -0400, Tom Lane wrote:
> I've been trying to get erserver to work with the current JDBC driver,
> and finding that it doesn't work very well. The problem is that there
> are many places in which a function creates a Statement, executes it
> to get a ResultSet, closes the Statement, and returns the ResultSet to
> its caller. This pattern worked okay in JDBC 7.0, but it fails
> completely with the current driver, because Statement.close() thinks
> it should close the last result set returned by the statement.
As others have said, this behaviour is required by the JDBC spec. This
actually makes sense in the general case, as a ResultSet implementation that
doesn't read all data at once may rely on resources managed at the Statement
level for continued operation.
> I've been able to sort-of work around this by commenting out the
> explicit close calls, but this doesn't really work, because the
> created Statement object has no references once control has left
> the calling function. A garbage-collection pass would finalize the
> Statement and thereby zap the ResultSet, whether or not there are
> still any valid references to the ResultSet.
Actually this should work fine as a ResultSet must hold a reference
(directly or indirectly) to the Statement that created it to implement
ResultSet.getStatement(). The postgresql driver's ResultSet implementation
holds this reference directly in a field of AbstractJdbc1ResultSet. So whatever
GC-related problems you are seeing are likely to have another cause.
Relying on finalization to do resource cleanup can be risky, though, since
it's not guaranteed to happen in a timely fashion (or ever, for that
matter). Witness the fun JDK1.4 has with NIO direct buffers & GC ..
-O
