In the embedded client, ResultSet#refreshRow throws a not implemented
exception. In the client driver, it is implemented as a no-op for
the updatable result set types we support, although it has some cruft
for sensitive result sets - from a previous life?
Checks are performed to see if the method is callable given the
state of the result set, but no actual refresh is attempted. This is
correct for scroll insensitive result sets, btw.
The client implementation is wrong in another respect: (Quote from
JDBC 3.0 API javadoc):
"If refreshRow is called after calling an updater method, but before
calling the method updateRow, then the updates made to the row are
As far as I can see, since this is implemented as a no-op, this
implicit update canceling does not happen.
I think we should reconcile the driver behaviors, probably by having
the client throw a not implemented exception as well. It is not
really needed for scroll insensitive result sets.