Only looking at the way the update row is implemented in the
EmbedResultSet it looks correct but inefficient.
Every time a column is updated a new DataValueDescriptor implementation
instance is created, this is a short lived object that will be garbage
collected. This doesn't match the way values are set in
EmbedPreparedStatement and EmbedCallableStatement. As an example calling
updateInt will result in something like
tempDvd = new SQLInteger();
tempDvd.setValue(value);
colDvd.setValue(tempDvd);
// discard tempDvd
While this looks ok-ish, when you consider having a ResultSet of a
milltion rows and updating them that's a lot of objects going thorough
the garbage collector for no value. The goal for Derby is to not create
objects on a per-row basis during SQL processing, unless obligated by
Java/JDBC semantics.
If the updateXXX() methods followed the pattern of the setXXX methods in
EmbedPreparedStatement then your updateColumn() method would change to
return the DataValueDescriptor to modify, thus updateInt() would be coded:
updateColumn(columnIndex).setValue(value);
though I think updateColumn would need to be renamed to better reflect
its role.
Similar for the arrays and their contents that manage the update row and
the state of the current row, these are discarded after every next() or
update of the row. It would be better if the objects were re-used.
Dan.
