db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yip Ng (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 22:16:28 GMT

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

Yip Ng commented on DERBY-2195:
-------------------------------

Hi Bryan.  Indeed, I have the same question too when I was fixing this jira.  

At first glance, it appears that it makes sense to call statement context clean up code when
an exception has occurred in the class that creates the new statement context.  However, this
does not work well when Server side JDBC comes into play.  The cleanup mechanism for invoking
a Java procedure has a different cleanup code path that uses the global context stack and
will clean up the various contexts in the order that they were pushed down till the "last
context handler".  I think the "last context handler" concept is for handling in the case
where the system does not want to rollback the entire execution context but to a certain statement
context.  (e.g.:  CALL statement may be executing various SQL statements and each of those
statement has its own statement context.  If one SQL statement fails with exception and the
Java procedure decides to handle the exception, it must not rollback the entire execution
context but only up to the statement context object that fails, and then the Java procedure
continues on.)   

So if a statement context cleanupOnError() is called within the place where it pushes it,
the sc will be cleaned and removed from the global stack and the exception is rethrown to
the next exception handler which will eventually invoke ContextManager's cleanupOnError method
and cleans up on the current global context stack.  So a statement context here is cleaned
up too soon and if for some reason, the outermost statement (CALL statement) needs to access
its statement context (i.e.:  sc.clearSavePoint()), it will throw an internal exception since
the outermost statement context has been popped off.  (see GenericStatementContext's pleaseBeOnStack()).

Hence, I think that that is why the SPS (GenericPreparedStatement) does not clean up the statement
context on error but rely on other classes or mechanisms such as GenericTriggerExecutor or
ContextManager's cleanupOnError() for proper cleanup.



> 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