Deadlock classification

Question

I apologize for the length of this post. I am trying to develop a methodology for classifying deadlocks based on the profile in their trace file and to reliably recreate them. There are many gaps in my understanding and I would appreciate the considered advice of a deadlock specialist.
For background, please refer to Exhibit A: http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/consist.htm#i5704
In my experience, there are 3 main types of deadlock:
Deadlock Type 1. Classic deadlock
This is the textbook case of "bad application logic": two sessions requesting resources out of order. This type of deadlock only occurs on updates, never on inserts.
Sample trace file:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-0001002c-00000ca4        18     146     X             20     158           X
TX-0003001b-00000f02        20     158     X             18     146           X
session 146: DID 0001-0012-0000070D session 158: DID 0001-0014-00000052
session 158: DID 0001-0014-00000052 session 146: DID 0001-0012-0000070D
Rows waited on:
Session 158: obj - rowid = 00010ABE - AAAQq+AAEAAAN8PAAA
  (dictionary objn - 68286, file - 4, block - 57103, slot - 0)
Session 146: obj - rowid = 00010ABD - AAAQq9AAEAAAN8HAAA
  (dictionary objn - 68285, file - 4, block - 57095, slot - 0)In plain English, the graph is saying,
Session 146 has an X lock on Resource A and is waiting for an X lock on Resource B.
Session 158 holds an X lock on Resource B and is waiting for an X lock on Resource A.
Questions:
* What is the meaning of the Resource Names (TX-0001002c-00000ca4 and TX-0003001b-00000f02)? Obviously these names refer to the tables being updated, but is the TX-* identifier something I can look up in the data dictionary somewhere?
* Likewise, what do the DID * identifiers refer to?
Steps to reproduce this kind of deadlock:
create table a(c int);
insert into a values(1);
insert into a values(2);
create table b as select * from a;
-- Session 1:
update a set c=2 where c=1;
-- Session 2:
update b set c=2 where c=1;
update a set c=2 where c=1;
-- (session 2 hangs at this point)
-- Session 1:
update b set c=2 where c=1;
-- (session 2 deadlocks at this point)
Deadlock Type 2. DML on a bitmap index
Frequent inserts and updates on a table with a bitmap index are resource intensive and can also cause deadlocks because as the index is being updated it places a lock on the rows that are associated with the index branch it is updating. If the transaction does not commit quickly enough, there can be time for another session to pop in and try to lock the same resources. This kind of deadlock can occur on both updates AND inserts.
Sample trace file:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-001d0004-000076fc        22      31     X             21      39           S
TX-001e0050-00007700        21      39     X             22      31           S
session 31: DID 0001-0016-00000002      session 39: DID 0001-0015-00000002
session 39: DID 0001-0015-00000002      session 31: DID 0001-0016-00000002
Rows waited on:
Session 39: obj - rowid = 00036241 - AAA2JBAAEAAAKAKAAA
Session 31: no rowNow, instead of waiting to obtain X-locks, the blocked sessions are waiting for S-locks.
Questions:
* S (share-table) locks lock the entire table (according to table 13-3 in Exhibit A). However, I have read that when a bitmap index is updated, it only locks the rows affiliated with that index entry, not the entire table. Can someone explain this apparent discrepancy?
* In the Rows waited on section, sometimes I see "no row" for both sessions and I don't understand why. I guess I need a common-sense explanation of what is going on at the index level in the case of bitmap index updates.
Steps to recreate:
create table a(c int);
create bitmap index BI_A on a(c);
insert into a values(1);
insert into a values(2);
commit;
-- Session 1:
insert into a values(1);
-- Session 2:
insert into a values(2);
-- Session 1:
insert into a values(2);
-- (session 1 hangs)
-- Session 2:
insert into a values(1);
-- (deadlock in session 1)
Deadlock Type 3. Unindexed foreign key
This one is harder for me to understand. Suppose you have a parent and child table: If you were to update the child's foreign key, and there is no index on that column, then the whole of the parent table is locked for the duration of the update. (Question: is this correct? the whole table is locked?) Therefore if the transaction runs long enough, there is a chance another session will try to lock the same resources and cause deadlock. This kind of deadlock only occurs on updates of the foreign key, never on inserts.
Sample trace file:
I have never knowingly seen a trace file for this kind of deadlock so I'm not sure what the graph would look like. Can anyone fill me in here?
Steps to recreate:
Again, I am unsure how to consistently recreate this kind of deadlock. This is as far as I get:
create table p (p_id int primary key);
create table c (c_id int primary key, p_id int);
alter table c add constraint fk_c_p foreign key(p_id)
  references p (p_id) enable;
insert into p values(1);
insert into p values(2);
insert into c values(1,1);
insert into c values(2,2);
insert into c values(3,1);
insert into c values(4,2);
-- Session 1:
update c set p_id=1 where p_id=2;
-- Session 2:
update c set p_id=1 where p_id=2;
-- (session 2 hangs)However, I am unable to induce a deadlock in Session 2, so I cannot see the trace file lock graph created by this kind of deadlock. Can anyone make a suggestion?
Thanks; I appreciate any help that is offered.

Answer 1

Well, consider what happens when a deadlock occurs. (Assume the simple case of two sessions deadlocking on each other.) Both are waiters and blockers. That's the definition of a deadlock.
After three seconds, the deadlock is detected, and one of the sessions catches an ORA-00060.
Now, when that happens, the session that did not catch the error is still a blocker and a waiter.
The other session, which caught the ORA-00060, is a blocker, but is no longer waiting.
So, the deadlock situation does not last more than three seconds. There is no need for you to worry about finding and freeing them. Oracle will do that much for you. Your time is best spent trying to understand the root cause, and how to avoid the deadlock in the first place. If you need to, you can code your application to do something when it sees ORA-00060, say, rollback and restart the transaction.
Hope that helps,
-Mark