[
https://issues.apache.org/jira/browse/DERBY-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071702#comment-14071702
]
Dyre Tjeldvoll commented on DERBY-6665:
---------------------------------------
The lock conflict appears to be on SYSCONGLOMERATES. The DROP TABLE referenced
is blocked by a CREATE TABLE statement issued on the XA-connection inside
{{doXAWorkUniquePK()}} method; "create table derby532xa(i int, constraint
derby532xa_c primary key(i) initially deferred)". After this statement
{{XAResource.end()}} and {{XAConnection.close()}} are called.
The test gets an NPE from {{XAResource.prepare()}}. This call is supposed to
fail, but with an {{XAException}}. The catch block for {{XAException}} will
call {{assertXidRolledBack(xar, xid)}}, which isn't really an assert as it
attempts a {{rollback()}} and catches the resulting exception to verify that
the it is the expected one. Could it be that this attempted rollback is
necessary to release locks, even if it throws?
> Violation of deferred constraints not detected when conglomerates are shared
> ----------------------------------------------------------------------------
>
> Key: DERBY-6665
> URL: https://issues.apache.org/jira/browse/DERBY-6665
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.11.0.0
> Reporter: Knut Anders Hatlen
> Attachments: braindump.diff,
> derby-6665-01-aa-remove-uniquePKConstraintModes.diff,
> derby-6665-01-ab-useTableUUIDforCheckConstraints.diff, junit.diff
>
>
> See the following script:
> {noformat}
> ij version 10.11
> ij> connect 'jdbc:derby:memory:db;create=true';
> ij> create table t1(x int primary key);
> 0 rows inserted/updated/deleted
> ij> create table t2(x int primary key);
> 0 rows inserted/updated/deleted
> ij> create table t3(x int, constraint fk1 foreign key (x) references t1
> initially deferred, constraint fk2 foreign key (x) references t2 initially
> deferred);
> 0 rows inserted/updated/deleted
> ij> insert into t1 values 1;
> 1 row inserted/updated/deleted
> ij> autocommit off;
> ij> insert into t3 values 1;
> 1 row inserted/updated/deleted
> ij> insert into t2 values 1;
> 1 row inserted/updated/deleted
> ij> delete from t1;
> 1 row inserted/updated/deleted
> ij> commit;
> ij> select * from t1;
> X
> -----------
> 0 rows selected
> ij> select * from t2;
> X
> -----------
> 1
> 1 row selected
> ij> select * from t3;
> X
> -----------
> 1
> 1 row selected
> {noformat}
> Since T3.X contains a value (1) that is not present in T1, the foreign key
> FK1 is violated, and the COMMIT statement should have failed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
