[
https://issues.apache.org/jira/browse/DERBY-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019326#comment-14019326
]
Dag H. Wanvik commented on DERBY-6576:
--------------------------------------
Adding a follow-up patch, derby-6576-repeatable-read. In the case where we do
not throw and exception because the deferred
unique/pk constraint referenced by an fk is upheld by another row, we need to
make sure that condition hold until we commit. This patch changes the check (in
ReferencedKeyRIChecker#isDuplicated) to scan using repeatable read isolation
level. This will
set a read lock on any duplicate row till transaction end and thus ensure
things are good till we commit.
> A immediate Fk constraint blows up iff its referenced PK is deferred and we
> modify a duplicate key column
> ---------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6576
> URL: https://issues.apache.org/jira/browse/DERBY-6576
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Reporter: Dag H. Wanvik
> Assignee: Dag H. Wanvik
> Fix For: 10.11.0.0
>
> Attachments: derby-6576-2.diff, derby-6576-3.diff,
> derby-6576-3.status, derby-6576-cascade-setnull.diff,
> derby-6576-cascade-setnull.status,
> derby-6576-forbid-deferred+cascade-set-null-1.diff,
> derby-6576-forbid-deferred+cascade-set-null-1.status,
> derby-6576-repeatable-read.diff, derby-6576.diff, derby-6576.status
>
>
> Similar to the issue in DERBY-6559, except here we modify the key in the
> referenced table. This leads Derby to check for any referencing FK and throw,
> even if there are other (formerly) duplicate rows that satisfy the FK
> constraint.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
