It was a good idea to try a deadlock involving a TM enqueue. You can find another interesting example of a TM enqueue here:
http://hoopercharles.wordpress.com/2010/01/07/deadlock-on-oracle-11g-but-not-on-10g/

Please keep in mind that a TM enqueue will not necessarily lead to a deadlock, and that a deadlock involving a TM equeue will not kill the sessions that ends up being the deadlock “victim” (this might not have been clear because of all of the incorrect quotes from the various books).

I had a little bit of trouble when I tried to recreate your test case:
In Session 1:

SELECT sys_context('USERENV', 'SID') FROM DUAL;

SYS_CONTEXT('USERENV','SID')
----------------------------
223

CREATE TABLE emp(
emp_id number(5) not null,
emp_name varchar2(35) not null,
address varchar2(50),
CONSTRAINT empid_pk PRIMARY KEY (emp_id)
);

INSERT INTO emp VALUES (1, 'xyz', 'addr1');
INSERT INTO emp VALUES (2, 'abc', 'addr2');
COMMIT;

DELETE from emp WHERE emp_id = 1;

In Session 2:

SELECT sys_context('USERENV', 'SID') FROM DUAL;

SYS_CONTEXT('USERENV','SID')
----------------------------
222

CREATE TABLE dept
(dept_id     number(8)     not null,
dept_name    varchar2(35)    not null,
emp_id     number(5)     not null,
CONSTRAINT fk_emp
FOREIGN KEY (emp_id)
REFERENCES emp(emp_id) ON DELETE CASCADE
);

CREATE TABLE dept
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

I could not create the DEPT table in Session 2 because Session 1 was already a TX lock on the EMP table. We need to change the order of the commands a little.

Fixing up the order of the commands and modifying the script to actually trigger a deadlock:
In Session 1:

ROLLBACK;

In Session 2:

ROLLBACK;

In Session 1:

CREATE TABLE dept
(dept_id     number(8)     not null,
dept_name    varchar2(35)    not null,
emp_id     number(5)     not null,
CONSTRAINT fk_emp
FOREIGN KEY (emp_id)
REFERENCES emp(emp_id) ON DELETE CASCADE
);

INSERT INTO dept VALUES (1, 'dep1', 1);
INSERT INTO dept VALUES (2, 'dep2', 1);
INSERT INTO dept VALUES (3, 'dep3', 2);
COMMIT;

DELETE from emp WHERE emp_id = 1;

In Session 2:

INSERT INTO emp VALUES (3, 'abc', 'addr2');
 
DELETE from emp WHERE emp_id = 2;

(Session 2 is hung)

In Session 1:

INSERT INTO emp VALUES (3, 'abc', 'addr2');

Session 2 Shows:

DELETE from emp WHERE emp_id = 2
            *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource

(Session 1 is still hung)

In Session 2:

SELECT
  *
FROM
  EMP
WHERE
  EMP_ID=3;
 
EMP_ID EMP_NAME                            ADDRESS
------ ----------------------------------- -------
     3 abc                                 addr2

The above shows that Session 2 was still connected to the database, and that the first row inserted by Session 2 was not rolled back by an automatic transaction rollback (there was an automatic statement-level rollback).

This is the deadlock graph that was written to the trace file:

Deadlock graph:
                       ---------Blocker(s)--------  ---------Waiter(s)---------
Resource Name          process session holds waits  process session holds waits
TX-00040016-0000085a        23     222     X             31     223           S
TM-00011c1a-00000000        31     223    SX             23     222    SX   SSX
 
session 222: DID 0001-0017-000002D9	session 223: DID 0001-001F-00000001 
session 223: DID 0001-001F-00000001	session 222: DID 0001-0017-000002D9 
 
Rows waited on:
  Session 222: no row
  Session 223: no row
 
----- Information for the OTHER waiting sessions -----
Session 223:
  sid: 223 ser: 25 audsid: 235217 user: 62/TESTUSER
    flags: (0x45) USR/- flags_idl: (0x1) BSY/-/-/-/-/-
    flags2: (0x40008) -/-
  pid: 31 O/S info: user: SYSTEM, term: AIRFORCE-1, ospid: 15824
    image: ORACLE.EXE (SHAD)
  client details:
    O/S info: user: hooper, term: AIRFORCE-1, ospid: 9392:15596
    machine: AIRFORCE-1 program: sqlplus.exe
    application name: SQL*Plus, hash value=3669949024
  current SQL:
  INSERT INTO emp VALUES (3, 'abc', 'addr2')
 
----- End of information for the OTHER waiting sessions -----

SQL> SELECT sys_context('USERENV', 'SID') FROM DUAL;

SYS_CONTEXT('USERENV','SID')
-----------------------------
140

CREATE TABLE emp(
emp_id number(5) not null,
emp_name varchar2(35) not null,
address varchar2(50),
CONSTRAINT empid_pk PRIMARY KEY (emp_id)
);

INSERT INTO emp VALUES (1, 'xyz', 'addr1');
INSERT INTO emp VALUES (2, 'abc', 'addr2');
COMMIT;
    EMP_ID EMP_NAME                            ADDRESS
---------- ----------------------------------- --------------------------------------------------
         1 xyz                                 addr1
         2 abc                                 addr2

DELETE from emp WHERE emp_id = 1;

session2:

SQL> SELECT sys_context('USERENV', 'SID') FROM DUAL;

SYS_CONTEXT('USERENV','SID')
--------------------------------------------------------------------------------
21

CREATE TABLE dept
(dept_id     number(8)     not null,
dept_name    varchar2(35)    not null,
emp_id     number(5)     not null,
CONSTRAINT fk_emp
FOREIGN KEY (emp_id)
REFERENCES emp(emp_id) ON DELETE CASCADE
);

INSERT INTO dept VALUES (1, 'dep1', 1);
INSERT INTO dept VALUES (2, 'dep2', 1);
INSERT INTO dept VALUES (3, 'dep3', 2);
COMMIT;

SQL> select * from dept;

   DEPT_ID DEPT_NAME                               EMP_ID
---------- ----------------------------------- ----------
         1 dep1                                         1
         2 dep2                                         1
         3 dep3                                         2

DELETE from emp WHERE emp_id = 2;

(session2 hangs here)

session3:

SQL> select sid,serial#,SECONDS_IN_WAIT,STATE,BLOCKING_SESSION,BLOCKING_SESSION_STATUS,event from v$session;

       SID    SERIAL# SECONDS_IN_WAIT STATE               BLOCKING_SESSION BLOCKING_SE EVENT
---------- ---------- --------------- ------------------- ---------------- ----------- ---------------------------------
        21      22260              10 WAITING                          140 VALID       enq: TM - contention
        140     29720              25 WAITING                              NO HOLDER   SQL*Net message from client
........... (edited due to many results)

I think that you are right – it is a bit of a mistaken cause and effect relationship, where the application’s reaction to the ORA error is missing element.

What you quoted above is very well worded – and matches the test case results at the start of this article. Thank you for posting the quote.

http://jonathanlewis.wordpress.com/2011/08/29/deadlock-2/

In the third OTN link you’ve listed, I gave the following answer
”
When deadlock occurs Oracle will not roll back the entire transaction. It will only do a rollback of one of the statements (belonging to one of the sessions) involded in the deadlock. The other session remains blocked if the session for which one of the statement has been rolled back by Oracle will not commit or rollback.

In other words, in the Justin Cave example, Session 1 will remains blocked if Session 2 will not issue a rollback after it has received the deadlook error

So, the OP should verify that his application must forsee a rollback in case of exception (and the deadlock error could be one of those exceptions)

Hope this helps
”
.