[
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: 10.10.0.0
> 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
