db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3897) SQLSessionContext not correctly initialized in some non-method call nested contexts
Date Wed, 08 Oct 2008 22:07:44 GMT

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

Dag H. Wanvik commented on DERBY-3897:
--------------------------------------

> 2) there's a fix to a context stacking bug

The bug is that such non-call cases were not addressed at all, so they
ended up with a "blank" session context (as if the substatement
executed on the top level of the connection, just after a fresh
connect). The new cases are those places in the code where I now call
executeSubstatement() instead of execute(). You'll notice that
executeSubstatement sets up a session context by calling
setupSubStatementSessionContext (which only reuses the parent
activation's session context).

In contrast, the call case is handled with the call to
setupNestedSessionContext (from generated code, cf
StaticMethodCallNode). Hope this helps :)

I'll have a look at the comments again.


> SQLSessionContext not correctly initialized in some non-method call nested contexts
> -----------------------------------------------------------------------------------
>
>                 Key: DERBY-3897
>                 URL: https://issues.apache.org/jira/browse/DERBY-3897
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.5.0.0
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>             Fix For: 10.5.0.0
>
>         Attachments: derby-3897-1.diff, derby-3897-1.stat, derby-3897-repro.diff
>
>
> In some contexts, beside calling stored routines containing SQL, Derby
> uses nested execution contexts, wehere we have two nested activations,
> but no nested connections.
> In such cases, currently a new SQLSessionContext is constructed, but
> not initialized correctly.  This leads to the session variables
> CURRENT_ROLE/CURRENT_SCHEMA not being set correctly in these contexts
> (they should inherited from the parent context, cf DERBY-3327).
> For method calls, this is being handled by generating a call to
> lcc.setupNestedSessionContext (see
> StaticMethodCallNode#generateSetupNestedSessionContext)
> In some of these nested contexts, one or both of the session variables
> CURRENT_ROLE/CURRENT_SCHEMA can be referenced, in others
> not. Obviously, if they can, this will lead to errors. The following
> contexts will have this problem:
> - ALTER TABLE ADD COLUMN <colname> <coltype> DEFAULT CURRENT_ROLE
>   In the AlterTableConstantAction, a nested UPDATE statement is used
>   to give existing rows the new column its default value. This
>   execution context is nested, cf. AlterTableConstantAction#executeUpdate
> - TRIGGER body execution may reference CURRENT_ROLE/CURRENT_SCHEMA.
>   The body executes in a nested context,
>   cf. GenericTriggerExecutor#executeSPS.
> In other cases, the session variables can not be referenced, so this
> not a problem: 
> - CHECK constraint execution
> - EmbedResultSet.insertRow, .deleteRow, .updateRow
> The session context should not be changed (pushed) for these nested
> executions, since there is no nested connection (SQL 2003, 4.37.1: "An
> SQL-session is associated with an SQL-connection.")

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message