Hello,
As I am sure most of you are aware Kathy and I have been working on
DERBY-213 (http://issues.apache.org/jira/browse/DERBY-213) for while
now. We have recently put the finishing touches on a promising patch
when I ran into a little snag. Somehow while looking over the code I
managed to overlook this comment until recently:
/*
* From Connection.setAutoCommit() javadoc:
* The commit occurs when the statement completes or the next execute
occurs, whichever comes first.
* In the case of statements returning a ResultSet object, *the
statement completes when the
* last row of the ResultSet object has been retrieved* or the
ResultSet object has been closed.
*/
This may or may not be a problem. The nature of our change to the client
side code is to make sure the closeX() method is only called on errors
or explicit close requests, a closed server side ResultSet or exceptions
rather then the first time the .next() method returns false. However at
the moment all of the autocommit logic is in the closeX() method, so by
altering when the closeX() function is called we are altering the
autocommit logic. This comment would seem to indicate that we must by
necessity commit any changes to the ResultSet when the last row of the
ResultSet is retrieved but I'm not sure what there is to commit. I
believe all of the .getXXX() calls to the ResultSet are readOnly,
.updateXXX() calls must be finalized with the UpdateRow() method before
the .next() method is called or the updates will be discarded and insert
functionality is not supported by the Client Driver.
So are we doing any harm by releasing this patch or is this the fix we
are looking for? The proposed changes do not seem to cause any problems
in the derbyall suite but this may be a lapse in the test suite rather
then good design decisions on our part.
Philip
