[
https://issues.apache.org/jira/browse/DERBY-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12922280#action_12922280
]
Knut Anders Hatlen commented on DERBY-4849:
-------------------------------------------
I agree that 2a sounds like a good approach. Some comments on the patch:
The name of the flag and the method may cause some confusion. The flag is set
if the execution failed because the plan was invalidated. The plan has not
necessarily been recompiled at that time, and the recompiling may in fact be
performed by the same thread after processing the exception, if no other thread
beats it to it. So perhaps rename to planWasInvalidated?
I'm wondering, though, what's the intended behaviour when the execution fails
for some other reason? Currently we add rows into SYSXPLAIN_STATEMENTS
regardless of the statement's successful execution, but should we have been
suppressing all failed executions? If so, we could set the flag unconditionally
in cleanupOnError(). But that may be outside the scope of this issue, unless
it's obvious that the current behaviour is unintended.
Do we know for sure that StandardException.getMessageId() will never return
null? Probably... But just to be 100% that we don't cause a NPE in the error
handling, should we turn around message id check in cleanupOnError() and call
equals() on LANG_STATEMENT_NEEDS_RECOMPILE, which is known to be non-null?
The comment in cleanupOnError() has a small typo: s/optimalization/optimization/
> Re-compilation may cause duplicate entries in the XPLAIN table
> --------------------------------------------------------------
>
> Key: DERBY-4849
> URL: https://issues.apache.org/jira/browse/DERBY-4849
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.6.2.1, 10.7.0.0
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: derby-4849-1a-narrow_fix.diff,
> derby-4849-2a-broad_fix.diff, derby-4849-xplain_duplicate_stacktrace.txt
>
>
> If happening at the right moment, a re-compilation request may cause
> duplicate entries in the XPLAIN statement tables.
> I have only confirmed this for the SYSXPLAIN_STATEMENTS table, and I do not
> know if the other XPLAIN tables are affected.
> The error is highly intermittent, and so far I have only been able to trigger
> it when testing the automatic index statistics update prototype.
> See the attached stack-trace for some more details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
