[ http://issues.apache.org/jira/browse/DERBY-2195?page=all ]
Yip Ng updated DERBY-2195:
--------------------------
Attachment: derby2195-trunk-stat01.txt
derby2195-trunk-diff01.txt
Attaching derby2195-trunk-diff01.txt for DERBY-2195. The patch fixes the
stated problem of this jira. After looking at the trigger code in more detail,
it appears that
the system is not cleaning up the statement context properly. The cleanup
should have been performed in GenericTriggerExecutor's executeSPS exception
handler (see patch for further comments).
In addition, there is another potential problem with the exception handling
logic in executeSPS() where it assumes that the SPS has executed and therefore
will have a new statement context and pops it off from the LCC. This is
somewhat dangerous as StandardException can occur before pushing the new
statement context to the stack; hence, this might result in popping the wrong
statement context. So the patch also addresses this issue.
derbyall and junit suite passes. Appreciate if someone can review this.
Thanks and happy New Year!
> 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.2.1.6, 10.3.0.0, 10.1.3.1
> 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