[
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
