[
https://issues.apache.org/jira/browse/DERBY-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel John Debrunner updated DERBY-1876:
-----------------------------------------
Attachment: ers_current_row.txt
>From an earlier comment:
------------------------------------------------------------------------------------------------
4) this.currentRow = factory.getValueRow(columnCount);
currentRow.setRowArray(null);
The call to getValueRow() creates a ValueRow with a new DataValueDescriptor
array within it, the next line nulls out the reference to the array. Thus this
creates a short lived object for no value.
------------------------------------------------------------------------------------------------
ers_current_row.txt is a patch that changes how currentRow is used in
EmbedResultSet. Now it is null to indicate the ResultSet is not positioned on a
row, or not null and it points to the currrent row. The current row in the
resultset is directly pointed to, which is what previously occurred, though at
the DVD[] level and not the Row level.
Running tests on the patch.
> Investigate overhead of JDBC layer and compiled activation code for simple
> embedded read-only, forward ResultSets
> -----------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1876
> URL: https://issues.apache.org/jira/browse/DERBY-1876
> Project: Derby
> Issue Type: Improvement
> Components: JDBC, Performance
> Reporter: Daniel John Debrunner
> Priority: Minor
> Attachments: derby1862.java, derby1876.java, ers_current_row.txt,
> timeout_colcount.diff
>
>
> For simple ResultSet usage like:
> ResultSet rs = ps.executeQuery();
> while (rs.next()) {
> rs.getInt(1);
> rs.getInt(2);
> rs.getInt(3);
> }
> rs.close();
> it would be interesting to see how much overhead could be removed with simple
> changes, or possibly removed if there was a simple ResultSet implementation
> for forward only, read-only ResultSet, and the more complete implementation
> for all other ResultSet types such as updateable and/or scrollable. Has
> introducing updateable ResultSets, for example, degraded the performance of
> read-only ResultSets? Could code be changed so that a typical read-only
> Resultset is not affected by the code required for richer ResultSets?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
