And about ResultSet the API documentation says:
"A |ResultSet| object is automatically closed when the |Statement|
object that generated it is closed, re-executed, or used to retrieve the
next result from a sequence of multiple results."
This implies that there is (should be) no valid ResultSets for a
Statement other than the "current" ResultSet. This completes the passage
quoted below.
Peter
Kevin Schmidt wrote:
> 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
>>
>>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org