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.
>
> 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.
>
> The above programming pattern seems perfectly valid to me, and
> accordingly I think that Statement.close() is broken. The current
> behavior foregoes all the advantages of Java's memory management model
> and turns them into liabilities. Instead of letting garbage collection
> do what it's supposed to, the programmer is forced to hang onto
> references to one object in order to preserve the validity of a
> different object.
>
> Comments?
How is the automatic cursor code controlled by setFetchSize() affected
by a Statement.close() before the result set is consumed? Does that need
to use holdable cursors here because in turn the transaction around the
cursor could end sooner than expected?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #