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".