Hallo,
1.)
I think that the implementation of the class ResultSet is not consistent
with the intention of the JDBC2 API designer. The intention of the API
designer was clearly to use a server side cursor for the ResultSet, this is
why the ResultSet.getCursorName() exists. Also, look at methods like
java.sql.ResultSet.absolute(int) for example. The API Spec. says: "Moves the
cursor to the given row number in the result set." and similar. (The current
implementation caches the whole result set on the client side.)
2.)
The PostgreSQL backend has the very nice feature that the cursor can be
moved back and forth. (With Oracle and Sybase you can move the cursor only
forward [I was told that ORA9i supports backward cursor movement, but I did
not check].)
3.)
There may exist a number of applications relying on the current behaviour
(full client side caching by the jdbc-driver). Based on mails on this list I
know of at least one implementation that keeps the result set returned from
Statement.execute() and uses it later, while the connection itself is
already being used by some other thread.
Proposal:
Let's provide two implementations for the ResultSet: the default would be
the current implementation, and another optional (activated through
properties or something) using server side cursor. I have not yet looked
very closely at the feasibility of my proposal, but on the face of it, it
can be implemented. First I'd like to monitor people's opinion about this.
Peter
PS:
I have to go off line for a few days next week, but I will (I hope) return.