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] [Updated] (DERBY-6003) Create row templates outside of the generated code
Date Wed, 05 Dec 2012 14:24:58 GMT

     [ https://issues.apache.org/jira/browse/DERBY-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Knut Anders Hatlen updated DERBY-6003:
--------------------------------------

    Attachment: d6003-3b-downgrade-workaround-in-tests.diff

Attaching a new patch (d6003-3b-downgrade-workaround-in-tests.diff) which provides an alternative
to the 3a patch for working around the downgrade issues.

Instead of making the engine stop storing SPS plans in the database when running in soft upgrade
potentially from one of the affected versions, this patch adds the workaround to the upgrade
tests.

The upgrade tests already have workarounds for the downgrade bug, but those workarounds are
spread across multiple test cases. Also, this issue will change the format for more trigger
plans, so that most triggers will hit the bug.

The patch therefore removes the various workarounds for DERBY-4835, DERBY-5105, DERBY-5263
and DERBY-5289, and replaces them with one centralized workaround. By centralizing the workaround,
it should be safe to add more trigger test cases to the upgrade tests later without worrying
abut the downgrade issue.

The new workaround adds a test case that runs last in the soft upgrade phase if the old version
suffers from DERBY-4835 or DERBY-5289. The new test case calls a stored procedure that clears
all SPS plans in SYS.SYSSTATEMENTS. This should make it safe to boot the database again in
the post soft upgrade phase, as there won't be any stored plans that cause deserialization
issues.

I was hoping to use the new SYSCS_UTIL.SYSCS_INVALIDATE_STORED_STATEMENTS procedure for this.
Unfortunately, it only invalidates the stored statements in memory, and leaves their disk
representation untouched, so I had to let the test define its own procedure to do this. I
also had to expose the clearSPSPlans() methods through the DataDictionary interface so that
the test procedure could call it.

This alternative patch avoids the potential performance degradation for users running soft
upgrade from 10.8 or earlier, as it's worked around entirely in test code, with the exception
of the addition of the one method to the DataDictionary interface. If there are no objections
to the approach, I intend to go for this patch and drop the 3a patch.
                
> 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, d6003-3a-safe-downgrade.diff,
d6003-3b-downgrade-workaround-in-tests.diff, d6003-4a-scanresultset.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

Mime
View raw message