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] Updated: (DERBY-3897) SQLSessionContext not correctly initialized in some non-method call nested contexts
Date Mon, 06 Oct 2008 16:39:44 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dag H. Wanvik updated DERBY-3897:

    Attachment: derby-3897-1.stat

Uploading a patch that also sets up a SQL session context correctly
also for "substatements". Substatements are statements that are
executed as part of the execution of a top level statement of a
connection (top level or nested). Currently the code already handles
the case of pushing session context for stored routines which can have
nested connections.

For substatements, the SQL session context is set up to be the same
(an alias) as the parent statement. I chose to set up the correct
session contexts also for constaints and the EmbedResultSet usages of
execute, even though it may be strictly unnecessary. It seems better
to alwas have the correct session context even if it not needed
(yet). It could become needed later for session state variables we
have not yet imlemented, e.g. current transaction isolation level.

New tests cases have been added, which reproduce the error if the rest
of the patch is not applied. Regressions ran cleanly.

Detailed patch comments:

M      java/engine/org/apache/derby/iapi/sql/conn/LanguageConnectionContext.java
M      java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java

- Split getNestedSessionContext in two: 
  setupNestedSessionContext and setupSubStatementSessionContext
- Made getTopLevelSQLSessionContext part of interface, needed by BaseActivation
- Moved lookup of parent activation to inside getCurrentSQLSessionContext
  (no behavior change, just simplifies usage code).
- Some renaming and comment changes.

M      java/engine/org/apache/derby/impl/sql/execute/GenericTriggerExecutor.java

- Now calls ps.executeSubStatement instead of ps.execute

M      java/engine/org/apache/derby/iapi/sql/Activation.java
M      java/engine/org/apache/derby/impl/sql/execute/BaseActivation.java

- renamed callActivation to parentActivation
- renamed nestedSQLSessionContext to sqlSessionContextForChildren
- renamed getNestedSQLSessionContext to getSQLSessionContextForChildren
  for better clarity of the code (hopefully!)
- split getNestedSQLSessionContext into two:
  setupSQLSessionContextForChildren(bool push) and getSQLSessionContextForChildren.
  setupSQLSessionContextForChildren now has logic to either push a new
  session context or inherit one as the case may be.
- renamed setCallactivation to setParentActivation
- renamed getCallactivation to getParentActivation

M      java/engine/org/apache/derby/impl/sql/execute/ConstraintConstantAction.java

- Now calls ps.executeSubStatement instead of ps.execute

M      java/engine/org/apache/derby/impl/sql/execute/AlterTableConstantAction.java

- Now calls ps.executeSubStatement instead of ps.execute

M      java/engine/org/apache/derby/iapi/sql/PreparedStatement.java
M      java/engine/org/apache/derby/impl/sql/GenericPreparedStatement.java

- Introduced 2 overloads of executeSubStatement, removed one existing
  overload of execute which is no longer used). The
  executeSubStatement contains a call to set up the substatement
  session context before the actual execute.
  The remaining execute method has lost an argument (did no longer vary).
- Comment changes and variable renaming to reflect new reality.

M      java/engine/org/apache/derby/impl/sql/GenericActivationHolder.java

- pass on new and changed methods

M      java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java

- Now calls ps.executeSubStatement instead of ps.execute

M      java/engine/org/apache/derby/impl/jdbc/EmbedStatement.java

- call to ps.execute has lost an actual argument
  (rollbackParentContext), see ps.execute body, always false. The true
  usages are found in calls to executeSubstatement now.

M      java/testing/org/apache/derbyTesting/functionTests/tests/lang/RolesConferredPrivilegesTest.java

Two new test cases.

M      java/testing/org/apache/derbyTesting/functionTests/tests/lang/SQLSessionContextTest.java

Comment referencing the new test cases in RolesConferredPrivilegesTest.

M      java/testing/org/apache/derbyTesting/junit/JDBC.java

Typo fix.

> 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:
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>             Fix For:
>         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:
>   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.

View raw message