db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2195) Nested triggers not working properly after maximum trigger count exception is thrown
Date Tue, 02 Jan 2007 21:16:27 GMT

    [ http://issues.apache.org/jira/browse/DERBY-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461826
] 

Bryan Pendleton commented on DERBY-2195:
----------------------------------------

Hi Yip, thanks for the explanation. It makes sense, but I'm wondering
whether this means that the cleanup is in the wrong place. Shouldn't
the code which handles pushing the new statement context also be
responsible for cleaning up that context if an exception is thrown? I guess
it just seems awkward if GenericTriggerExecutor has to store a copy of
the context in order to detect that some other class's method has pushed a new
context object which now requires cleanup. Is Trigger a special case 
which adds this additional complexity?

> Nested triggers not working properly after maximum trigger count exception is thrown
> ------------------------------------------------------------------------------------
>
>                 Key: DERBY-2195
>                 URL: http://issues.apache.org/jira/browse/DERBY-2195
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.1.3.1, 10.2.1.6, 10.3.0.0
>         Environment: Any
>            Reporter: Yip Ng
>         Assigned To: Yip Ng
>         Attachments: derby2195-trunk-diff01.txt, derby2195-trunk-stat01.txt
>
>
> After the maximum allowed nested trigger exception is thrown, subsequent statement that
result in nested trigger execution may result in the same error again even though it does
not exceed the limit of nested triggers(16).
> e.g.:
> C:\derby\trunk>java -classpath classes;. org.apache.derby.tools.ij
> ij version 10.3
> ij> connect 'jdbc:derby:wombat;create=true';
> ij> create table t1 (i int);
> 0 rows inserted/updated/deleted
> ij> insert into t1 values 1,2,3;
> 3 rows inserted/updated/deleted
> ij> create trigger tr1 after update on t1 for each row update t1 set i=i+1;
> 0 rows inserted/updated/deleted
> -- force the "maximum depth of nested triggers" error to occur
> ij> update t1 set i=i+1;
> ERROR 54038: Maximum depth of nested triggers was exceeded.
> ij> drop trigger tr1;
> 0 rows inserted/updated/deleted
> ij> create trigger tr1 after update on t1 referencing old as oldt for each row update
t1 set i=i+1 where oldt.i=2;
> 0 rows inserted/updated/deleted
> -- this should have executed successfully instead of throwing the same error again!
> ij> update t1 set i=i+1;
> ERROR 54038: Maximum depth of nested triggers was exceeded.
> ij> disconnect;
> ij> connect 'jdbc:derby:wombat';
> ij> select * from t1;
> I
> -----------
> 1
> 2
> 3
> 3 rows selected
> -- ok after reconnection, it looks like the trigger execution context(TEC) may not have
been cleanup properly in the previous connection
> ij> update t1 set i=i+1;
> 3 rows inserted/updated/deleted
> ij> select * from t1;
> I
> -----------
> 4
> 5
> 6
> 3 rows selected
> ij>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message