.
\nHere is an odd Oracle behavior I observed when a transaction that acquired a lock is rolled back. Note that this is related to a specific combination of locks that should not be encountered in production. So it’s not a bug. Just something unexpected.
\n
In my first session I lock the DEPT table in share mode (RS)
\n20:56:56 SQL1> lock table dept in row share mode;
\nTable(s) Locked.
\n
\nMy first session (SID=53) has acquired a TM lock in mode 2 (row share):
\n20:56:56 SQL1> select object_name,session_id,LOCKED_MODE from v$locked_object join dba_objects using(object_id);
\n
\nOBJECT_NAME SESSION_ID LOCKED_MODE
\n----------- ---------- -----------
\nDEPT 53 2
\n
\n
In my second session I lock the DEPT table in share + row exclusive mode (SRX). This is compatible with the RS.
\n20:56:59 SQL2> lock table dept in share row exclusive mode;
\nTable(s) Locked.
\n
\nMy second session (SID=59) has acquired a TM lock in mode 5 (share + row exclusive):
\n20:56:59 SQL2> select object_name,session_id,LOCKED_MODE from v$locked_object join dba_objects using(object_id);
\n
\nOBJECT_NAME SESSION_ID LOCKED_MODE
\n----------- ---------- -----------
\nDEPT 59 5
\nDEPT 53 2
\n
\nThen I rollback my transaction
\n20:56:59 SQL2> rollback;
\n
\nMy lock was released and I’ve only the one from Session 1 (SID=53):
\nOBJECT_NAME SESSION_ID LOCKED_MODE
\n----------- ---------- -----------
\nDEPT 53 2
\n
\nNow comes the funny part. I run exactly the same SSX lock, which was immediately acquired before:
\n21:14:30 SQL2> lock table dept in share row exclusive mode wait 5 ;
\n
\nBut now it hangs. Let’s see the blocking tree with utllockt.sql:
\nWAITING_SESSION LOCK_TYPE MODE_REQUESTED MODE_HELD LOCK_ID1 LOCK_ID2
\n----------------- ----------------- -------------- -------------- ----------------- -----------------
\n53 None
\n 59 DML Exclusive Row-S (SS) 94228 0
\n
\nWhat? My session wants to acquire an Exclusive lock? I’ve never requested that.
\nAnd finally it fails because my Session 1 has a RS lock which prevents exclusive locks.
\nlock table dept in share row exclusive mode wait 5
\n*
\nERROR at line 1:
\nORA-00054: resource busy and acquire with NOWAIT specified or timeout expired
\n
\n
But there is worse. I disconnect my second session and try to do the same from a third one. And I even try only a RS lock:
\n21:15:20 SQL3> lock table dept in row share mode wait 5 ;
\n
\nAnd I’m blocked again. It seems that because a session had acquired a SRX lock and has rolled back, while another session held a RS one, then any new transaction that wants to acquire any lock must acquire temporarily an exclusive one before.
\n
In order to get further I traced the locks with event 10704 (see how in a previous post).
\nHere is the trace when it failed, filtering on ‘00017014’ which is the object_id of DEPT in hexadecimal:
\nksqgtl *** TM-00017014-00000000-00000000-00000000 mode=2 flags=0x400 timeout=5 ***
\nksqrcl: TM-00017014-00000000-00000000-00000000
\nksqgtl *** TM-00017014-00000000-00000000-00000000 mode=6 flags=0x400 timeout=5 ***
\nksqcmi: TM-00017014-00000000-00000000-00000000 mode=6 timeout=5
\nksqcmi: returns 51
\nksqgtl: RETURNS 51
\nksqrcl: returns 0
\n
\nMy ‘lock table dept in row share mode’ acquires a mode 2 (which is the ‘row share’ mode) but then released it and tried to acquire a mode 6 (which is exclusive)
And then here is a trace when it was successful, after the transaction in Session 1 has been committed:
\nksqgtl *** TM-00017014-00000000-00000000-00000000 mode=2 flags=0x400 timeout=5 ***
\nksqrcl: TM-00017014-00000000-00000000-00000000
\nksqgtl *** TM-00017014-00000000-00000000-00000000 mode=6 flags=0x400 timeout=5 ***
\nksqcmi: TM-00017014-00000000-00000000-00000000 mode=6 timeout=5
\nksqcmi: returns 0
\nksqgtl: RETURNS 0
\nksqgtl *** TM-00017014-00000001-00000000-00000000 mode=3 flags=0x400 timeout=5 ***
\nksqgtl: RETURNS 0
\nksqcnv: TM-00017014-00000000-00000000-00000000 mode=2 timeout=5
\nksqcmi: TM-00017014-00000000-00000000-00000000 mode=2 timeout=5
\nksqcmi: returns 0
\nksqrcl: TM-00017014-00000001-00000000-00000000
\nksqrcl: returns 0
\n
\nSo it it did the same, but that time the mode 6 can be acquired. Then we see a conversion to mode 2 which is the RS we wanted.
Finally I tried with all other combinations of locks, but it seems that only that one (RS then rolled back SRX) show that behavior. I tried also with DML instead of ‘lock table’ statement but the Share lock acquired by DML (the non-indexed foreign key case) is released immediately so I cannot rollback it. And a failure in the statement do not trigger the same behaviour.
\nFinal note: the only reference I’ve find for that behavior is this post on oracle-l
\n", "protected": false } }