Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <13973455.30291287437670820.JavaMail.jira@thor>
Date: Mon, 18 Oct 2010 17:34:30 -0400 (EDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4849) Re-compilation may cause duplicate
 entries in the XPLAIN table
In-Reply-To: <2187405.138091287042456312.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.