This is expected behaviour since, as you point our in your follow-up comment, you’ve declared your foreign key constraint to be “on delete cascade”. This means that “delete from parent” start with a recursive “delete from child” – which has to take the mode 3 lock.

The following tests were performed on 10.2.0.3

test case 1: 1 parent table and 1 child table ; the FK is indexed and on delete cascade is defined.

1a. delete on parent takes mode 3 lock on parent and mode 3 on child which is apparently not expected in 10.2.0.3 .
1b. delete on child takes mode 3 on child and mode 2 on parent which is expected.

test case 2: 1 parent table and 2 child tables referencing it; the FKs are indexed and on delete cascade is defined.

1a. delete on parent takes mode 3 lock on parent and mode 3 on child1 and mode 2 on child 2 !!
1b. delete on child takes mode 3 on child and mode 2 on parent.

I wasn’t aware of the down-up-down either until your demonstration prompted me to run a 10704 trace to see exactly what the locking sequence was.

I think the comment I made on the “merge – argh!” note applies here: the example is just far enough outside the obvious list of tests that it wouldn’t be surprising if this side effect of the mode 2 / mode 3 change hadn’t been noticed. After all, I think you have to have a “missing” index and an insert that queues on delete or update that is already queueing on an uncommitted delete or update; I would imagine any test suite that defines a foreign key as “on delete cascade” would automatically include the foreign key index.

This was a demo that i made to a jr performance analyst to show him the concepts (performance impact) of not having an index on the foreign key. So, when i was saying that insert on the parent table should not get blocked on this specific case, i made “oops, this is odd”. Now i can explain thanks to you.

Moral of the story: Bad application design can stay even worse on 11g releases :)

That’s a lot easier to deal with. Forget all the stuff about write-consistency, I was fooled by the repetition of the ‘X’s in your original comment into thinking that you were deleting and re-inserting the same thing all the time. The example you’ve supplied arises through a combination of two things: (a) absence of a foreign key index when deleting parent keys (especially with “on delete cascade” on the foreign key, and (b) the change in 11g results in a mode 3 lock at the opposite end of a parent/child relationship rather than the mode 2 that used to be used in 9i and 10g.

The sequence is as follows:

Session 1 deletes from parent – gets mode 3 on parent, gets mode 5 on child because of absence of “foreign key” index, but ends up down-converting to mode 3.
Session 2 locks parent in mode 3, attempts to lock child in mode 5 – gets blocked by session 1
Session 3 locks parent in mode 3, attempts to lock child in mode 3 – gets blocked by session 2

Session 1 commits

Session 2 gets mode 5, and immediately down-converts to mode 3 (that’s just the way it works)
Session 3 is no longer blocked and gets mode 3 on the child, does the insert on the parent
Session 2 prepares to do the delete on the child and tries to up-convert to mode 5 – and gets blocked by session 3.

The oddity (or rather, the behaviour that I can’t think of an explanation for yet) is the way that Oracle down-converts from 5 to 3 when it does, forcing it to up-convert to do the delete. You could raise this with Oracle in an SR, but I suspect they would simply tell you to create an index on the foreign key.

The reason you don’t see the apparent breaking of FIFO in earlier versions of Oracle is that session 3 only takes out a mode 2 on the child in 9i and 10g when inserting on the parent, and session 2 is allowed to hold a mode 5 when other sessions are holding mode 2.

CREATE TABLE SUPPLIER
  (
    "SUPPLIER_ID"   NUMBER(10,0) NOT NULL ENABLE,
    "SUPPLIER_NAME" VARCHAR2(50 BYTE) NOT NULL ENABLE,
    "CONTACT_NAME"  VARCHAR2(50 BYTE),
    CONSTRAINT "SUPPLIER_PK" PRIMARY KEY ("SUPPLIER_ID") 
  );  
  
CREATE TABLE PRODUCT
  (
    "PRODUCT_ID"   NUMBER(10,0) NOT NULL ENABLE,
    "PRODUCT_NAME" VARCHAR2(50 BYTE) NOT NULL ENABLE,
    "SUPPLIER_ID"  NUMBER(10,0) NOT NULL ENABLE,
    CONSTRAINT "FK_SUPPLIER" FOREIGN KEY ("SUPPLIER_ID") REFERENCES ."SUPPLIER" ("SUPPLIER_ID") ON
  DELETE CASCADE ENABLE
  );
  
insert into SUPPLIER values (1,'Thiago Maciel','email');
insert into SUPPLIER values (2,'Jonathan Lewis','Blog - lock-horror');
commit;
insert into PRODUCT values(1,'Oracle',1);
insert into PRODUCT values(1,'Enqueue Kernel',2);
commit;

Session 1: DELETE SUPPLIER WHERE SUPPLIER_ID = 1;
Session 2: DELETE SUPPLIER WHERE SUPPLIER_ID = 2;
Session 3: INSERT INTO SUPPLIER VALUES (3,’lock Behavior 11gR2′,’Oracle Support’);

Wait Chains: Session 2 is being blocked by the session 1, and session 3 is being blocked by the session 2.

Session 1: commit;
Session 2: still blocked
Session 3: got the lock, and complete the insert command.

Wait Chains: Now, session 2 is being blocked by the session 3

Session 3: commit;
Session 2: got the lock, and complete the delete command.
Session 2: commit;

Session 1: select * from supplier;
SUPPLIER_ID SUPPLIER_NAME       CONTACT_NAME
----------- ------------------- --------------
          3 lock Behavior 11gR2 Oracle Support

There are lots of places where the manuals (and notes on Metalink) have not changed to reflect the way the software has changed. From time to time I use the “feedback” option to point out errors or omissions. You could do the same in this case.

I can’t comment on your question on locking because I didn’t see anything anomalous when I tried to emulate your code path on 11.2.0.2. (It behaved the same way on 9.2.0.8 and 10.2.0.3)

It seems to me, though, that there are two possible legal outcomes – although one of them is counter-intuitive.

a) Session 2 reports no rows deleted and session 3 inserts a row
b) Session 3 inserts a row and session 2 waits on session 3 to commit (actually, I’ve changed my mind about that, at least for the simplest cases – although if there is a child table involved I might want to re-think the issue).

Option (a) is the intuitively obvious one.

Option (b) could occur, in some circumstances perhaps, but is highly dependent on timing – if you are seeing it then it may be a legal example of “write-consistency”. Session 2 has to rollback and restart because the data it is supposed to modify has changed since the start of statement; this being the case it is possible for session 3 to be released to insert the new row. (It’s also possible that you’ve found a bug, of course.)

I haven’t been able to make (b) appear on 11.2.0.2.

Have you got a complete demonstration showing how to create the table, and listing every step along the way. Have you checked that you don’t have some setting (e.g. related to isolation level) that confuses the issue ?