[ 
https://issues.apache.org/jira/browse/DERBY-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920912#action_12920912
 ] 

Knut Anders Hatlen commented on DERBY-4849:
-------------------------------------------

I think I see what's going on.

BasicNoPutResultSetImpl.open() discovers that the statement has been 
invalidated, but only after the result set has actually been opened. It raises 
a LANG_STATEMENT_NEEDS_RECOMPILE exception to notice the caller that the result 
set is based on an invalid plan. The exception is caught and handled by this 
code in GenericPreparedStatement.executeStmt():

                        } catch (StandardException se) {
                                /* Cann't handle recompiling SPS action 
recompile here */
                                if 
(!se.getMessageId().equals(SQLState.LANG_STATEMENT_NEEDS_RECOMPILE)
                                                 || spsAction)
                                        throw se;
                                statementContext.cleanupOnError(se);
                                continue recompileOutOfDatePlan;

                        }

The call to statementContext.cleanupOnError(se) will eventually lead to close() 
being called on the result set. Since the XPLAIN tables are updated on close(), 
we'll get an entry for the result set even if it was never actually executed. 
Since GPS will re-execute the statement, we'll get a second entry for the 
actual execution.

I think this will only happen if the statement is invalidated between GPS's 
call to rePrepare() at line 409 and its call to resultSet.open() at line 436.

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

Reply via email to