Tom,
A ResultSet object is closed when it's Statement object is closed per
the JDBC spec. Look at the Javadoc on Statement.close() and it states
"When a Statement object is closed, its current ResultSet object, if one
exists, is also closed." At a higher level it also says that close
"Releases this Statement object's database and JDBC resources
immediately ..." and the ResultSet is one of those resources.
Kevin
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?
>
> regards, tom lane
>
>BTW, the error reported by ResultSet.next() in this situation is
>extremely misleading; it gripes about "connection closed" when it
>should say "result set closed".
>
>---------------------------(end of broadcast)---------------------------
>TIP 8: explain analyze is your friend
>
>