db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip Wilder <0505...@acadiau.ca>
Subject DERBY-213 Autocommit issue
Date Fri, 10 Jun 2005 14:37:57 GMT
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


Mime
View raw message