On 13/10/2003 01:23 Oliver Jowett wrote:
> [snip]
> 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 ..
ISTM that calling resultset.getStatement().close() after processing the
resultset might provide a reasonable fix.
--
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller
Business |
| Computer Consultants |
http://www.thomas-micro-systems-ltd.co.uk |
+------------------------------+---------------------------------------------+