[teiid-issues] [JBoss JIRA] (TEIID-2641) improve transaction handling in procedures

[Steven Hawkins (JIRA)]

     [ https://issues.jboss.org/browse/TEIID-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Hawkins resolved TEIID-2641.
-----------------------------------

    Resolution: Done


Addressed several issues:

1. we are not properly marking hold vs no_hold on procedures that do not return result sets.  A returnable statement will be returned as the result inadvertently if executed in the procedure.

2. loop cursors are not properly isolated with exception handling - if an exception is caught from a loop, the cursor will still exist afterwards and the use of a cursor with the same name after that will be erroneous.

3. error statements are not properly resolved as they are inadvertently being resolved as if they were a continuation of the block statements - they instead need to resolve against the parent scope.

4. on an exception the block is popped but not clearly handled.  We now will pop it as a failure and if there is a higher level transaction running it will be marked as rollback only.  This prevents the commit of partial atomic blocks.

After some investigation it does seem like proper behavior to allow variable assignments and the implicit cursor value to be non-transaction - that is as soon as the assignment is made it will be unaffected by rollback.  I'll update the docs to make this explicit.
                
> improve transaction handling in procedures
> ------------------------------------------
>
>                 Key: TEIID-2641
>                 URL: https://issues.jboss.org/browse/TEIID-2641
>             Project: Teiid
>          Issue Type: Bug
>          Components: Query Engine
>    Affects Versions: 7.6
>            Reporter: Steven Hawkins
>            Assignee: Steven Hawkins
>            Priority: Critical
>             Fix For: 8.5
>
>
> Atomic blocks do not have well-defined handling w.r.t. variable assignments and the implicit return cursor.  In both cases the affects are currently non-atomic - the last assignment/cursor is effective even.
> Also exception handling in an atomic block must result in an exception being thrown to guarantee the entire block atomicity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira