[ http://issues.apache.org/jira/browse/DERBY-1621?page=all ]
Yip Ng updated DERBY-1621:
--------------------------
Attachment: derby1621trunkstat02.txt
derby1621trunkdiff02.txt
Resubmitting patch derby1621trunkdiff02.txt for code cleanup. Although the
patch ran fine with derbyall, there is something not working properly with the
wait mechanism. I'll have to look into that.
On the code change side, I am alittle reluctant to modify the dependency
manager(DM) internals, perhaps there is a cleaner way to inform DM to use
another transaction controller(tc) object at execution time e.g. add a method
to alter the current transaction at execute time in LanguageConnectionContext
(lcc) and modify the lcc's getTransactionExecute() accordingly to return the
appropriate tc object. However, I am not entirely sure if that is a good idea
since there may be multiple threads running on the same connection, one thread
is doing SPS recompilation and sets the "alternative" transaction controller in
lcc, the other thread is doing an insert statement and when it queries the lcc
for its transaction controller, it may get the nested transaction controller
which is not right. Is this scenario possible? Comments?
> Trigger action statement is not recompile when there is a change that would
> affect it.
> --------------------------------------------------------------------------------------
>
> Key: DERBY-1621
> URL: http://issues.apache.org/jira/browse/DERBY-1621
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.2.0.0
> Reporter: Daniel John Debrunner
> Assigned To: Yip Ng
> Priority: Critical
> Fix For: 10.2.0.0
>
> Attachments: derby1621trunkdiff01.txt, derby1621trunkdiff02.txt,
> derby1621trunkstat01.txt, derby1621trunkstat02.txt
>
>
> A trigger action statement, such as an INSERT statement is not recompiled
> when there is some DDL change on the underlying table, such as a CREATE INDEX.
> In the example below a unique index is added to the table (t2) inserted into
> by the trigger's action statement. When the tirgger fires it does not raise
> any error (should raise a unique constraint violated error) and does not
> insert the value into the index. A select from t2 does not show the
> additional rows in t2 as it is performing an index scan, once the index is
> dropped the rows appear to the select.
> ij version 10.2
> ij> connect 'jdbc:derby:cs;create=true';
> ij> create table t (i int);
> 0 rows inserted/updated/deleted
> ij> create table t2 (i int);
> 0 rows inserted/updated/deleted
> ij> create trigger tt after insert on t for each statement mode db2sql
> insert into t2 values 1;
> 0 rows inserted/updated/deleted
> ij> insert into t values 1;
> 1 row inserted/updated/deleted
> ij> select * from t2;
> I
> -----------
> 1
> 1 row selected
> ij> create unique index tu on t2(i);
> 0 rows inserted/updated/deleted
> ij> insert into t values 1;
> 1 row inserted/updated/deleted
> ij> select * from t2;
> I
> -----------
> 1
> 1 row selected
> ij> insert into t values 1;
> 1 row inserted/updated/deleted
> ij> select * from t2;
> I
> -----------
> 1
> 1 row selected
> ij> drop index tu;
> 0 rows inserted/updated/deleted
> ij> select * from t2;
> I
> -----------
> 1
> 1
> 1
> 3 rows selected
--
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
