db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1876) Investigate overhead of JDBC layer and compiled activation code for simple embedded read-only, forward ResultSets
Date Fri, 22 Sep 2006 16:20:25 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1876?page=comments#action_12436898 ] 
Daniel John Debrunner commented on DERBY-1876:

I've thought in the past about having the common statistic information in a language ResultSet
implementation that could wrap the real langugae ResultSet. Then the ResultSetFactory would
return a instance of the real ResultSet wrapped with a StatisticsResultSet when timing etc.
was enabled. The StatisticsResultSet would have code like:

class StatisticsResultSet {
   private long openTime;

   private final ResultSet rs;

   pubic void openCore() {
       long s = System.currentTimeMillis();
       long e = System.currentTimeMillis();

       openTime += (e -s);

This then removes the common fields and code to get the times from all the ResultSet classes,
also leading to consistency.

The issue with this that code that performs instanceof checks to get specific behaviour of
a ResultSet no longer works, though there are  solutions to that:
    A) Don't do it, it breaks the api in that the ResultSetFactory says it is  returning a
ResultSet, so that's all the callers should depend on.
    B) Follow the JBDC wrapper model, have a getRealResultSet() call in ResultSet api which
would return this for most implementations, but the wrapped rs for StatisticsResultSet. Then
code that needed to access the specific class would use the return from that method.

> Investigate overhead of JDBC layer and compiled activation code for simple embedded read-only,
forward ResultSets
> -----------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-1876
>                 URL: http://issues.apache.org/jira/browse/DERBY-1876
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC, Performance
>            Reporter: Daniel John Debrunner
>            Priority: Minor
>         Attachments: derby1876.java
> 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.
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message