db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6003) Create row templates outside of the generated code
Date Thu, 29 Nov 2012 15:06:59 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506517#comment-13506517

Knut Anders Hatlen commented on DERBY-6003:

The next speed bump is deserialization issues on downgrade after soft upgrade.

The problem: Some old versions (those that don't have the fix for DERBY-3870 or DERBY-5289)
read all of SYS.SYSSTATEMENTS when detecting a version change, including the column that holds
the compiled plan. So if the format of the compiled plan changes between versions in a way
so that the old release cannot deserialize plans created by the newer version, booting the
database with the old version after soft upgrade may fail with deserialization errors.

DERBY-3870 and DERBY-5289 fixed this problem on upgrade, but left the downgrade problem unresolved.
For downgrade, they simply disabled the problematic test cases in the upgrade tests.

Since I intend to change the format of the stored plans as part of this issue, databases that
use triggers will run into this problem again if they are soft-upgraded from one of the broken
versions, and then later downgraded back to that version. So some handling of the downgrade
problem is needed. Otherwise, the upgrade tests that use triggers will fail when the old version
is one of the broken versions, and also users that are still on one of the broken versions,
may run into the problem if they do soft upgrade followed by downgrade.

One way to handle this might be to disable trigger test cases in upgrade tests when we are
using one of the broken versions. That won't fix the problem seen by users, though. Also,
it might require extra disabling logic in future test cases that use triggers, so it doesn't
even fix the testing once and for all.

An alternative I'm exploring now, and that looks promising, is to stop writing the compiled
plan of an SPS to disk if we are running in soft upgrade mode and the dictionary version is
so old that it is possible to downgrade to a version that might fail to boot because of the
new plan. We already do this for meta-data queries (actually even stricter: we never store
plans for meta-data queries in soft upgrade).

The only downside I can think of with this approach, is that trigger statements need to be
recompiled after each reboot when running in soft upgrade from one of the affected branches.
This should happen automatically, so users shouldn't notice much except, perhaps, that warmup
takes a little longer after a reboot if they have many triggers.

I think that sounds like a reasonable cost to avoid the deserialization errors. If users experience
performance degradation, they can always do a full upgrade and the trigger plans will be stored
to disk again.

By the way, this approach was briefly discussed in DERBY-5105, but it was skipped because
DERBY-5105 was so limited that a workaround in the upgrade tests was considered enough. If
we implement it, the workaround for DERBY-5105, as well as the workarounds for DERBY-4835,
DERBY-5263 and DERBY-5289, can probably be removed from the upgrade tests.
> Create row templates outside of the generated code
> --------------------------------------------------
>                 Key: DERBY-6003
>                 URL: https://issues.apache.org/jira/browse/DERBY-6003
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions:
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: d6003-1a-cleanup.diff, d6003-2a-unused-field.diff
> The constructors for many of the result set classes take GeneratedMethod parameters that
create row templates (an ExecRow of a certain size and column types, each column initialized
to an SQL null value).
> As an alternative, the compiler could produce an ExecRow instance and put it into the
savedObjects field of GenericPreparedStatement, and the constructors could take parameter
that points to the object in savedObjects. Where the result sets currently invoke the generated
method to produce a fresh template, they could instead clone the saved object.
> Advantages with the suggested approach would be:
> - Reduce the size of the code generator, which should reduce total code complexity.
> - Reduce the amount of generated code, which makes it easier for tools (profilers, static
code analyzers, IDEs) to map executable code to source code.
> - Reduce the actual number of generated methods, which makes it less likely that queries
need to use reflection to invoke the remaining generated methods (there's a switchover from
DirectCall to ReflectCall when the number of generated methods exceeds 10).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message