Paradox: Can a process deadlock itself?

Abstract: Cui Hua, net name dbsnake Oracle ACE Director, ACOUG core expert editor's note: Thanks to Cui Hua for authorizing us to exclusively reprint his excellent articles, and welcome everyone to contribute to the "Oracle" community. Before the new year, take a look at this small article by Cui Hua, through a simple example, to understand Oracle's self-made transactions and deadlocks, I suggest that you test and try, so as to learn more knowledge.
640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1
Cui Hua, net name dbsnake
Oracle ACE Director, ACOUG core expert
Editor note: Thanks to Cui Hua for authorizing us to exclusively reprint his excellent articles, and welcome everyone to contribute to the "Oracle" community. Before the new year, take a look at this small article by Cui Hua, through a simple example, to understand Oracle's self-made transactions and deadlocks, I suggest that you test and try, so as to learn more knowledge.
A friend asked me: "Will a transaction deadlock itself? That is, it locks itself."
Coincidentally, half a month ago, I just helped a colleague deal with this self-deadlock situation.
Let's construct an example of self-deadlock here:
select sid from v$mystat
where rownum<2;
       SID
——-
       362
SQL> create table t1 (id varchar2(10),
amount number(10));
Table created
SQL> insert into t1 values('cuihua',100);
1 row inserted
SQL> commit;
Commit complete
SQL> select * from t1;
ID              AMOUNT
———- ———–
cuihua             100
SQL> create procedure p_autonomous is
  2  PRAGMA  AUTONOMOUS_TRANSACTION;
  3  begin
  4  update t1 set amount=102
  5  where id='cuihua';
  6  commit;
  7  end;
  8  /
Procedure created
SQL> create procedure p_test is
  2 begin
  3 update t1 set amount=101 where id='cuihua';
  4 p_autonomous;
  5 commit;
  6  end;
  7  /
Procedure created
Now as long as I execute the above stored procedure p_test, it will generate self deadlock as follows:
640?wx_fmt=png&wxfrom=5&wx_lazy=1
At this time, the alert log will show:
ORA-00060: Deadlock detected.
More info in file /u01 /app/oracle/admin/ipra/udump/ipra_ora_921828.trc.
From the above trace file we can see:
640?wx_fmt=png&wxfrom=5&wx_lazy=1
That means the Blocker here is session 362, and Waiter is also session 362, typical locked himself.
Friends who don't know why I constructed this way will understand everything after reading the following passage:
The Oracle server provides the ability to temporarily suspend a current transaction and begin another. This second transaction is known as an autonomous transaction and runs independently of its parent. The autonomous or child transaction can commit or rollback as applicable, with the execution of the parent transaction being resumed upon its completion.
The parent may then perform further operations and commit or roll back without affecting the outcome of any operations performed within the child. The child transaction does not inherit transaction context (that is, SET TRANSACTION statements). The transactions are organized as a stack: Only the “top” transaction is accessible at any given time. Once completed, the autonomous transaction is “popped” and the calling transaction is again visible. The limit to the number of suspended transactions is governed by the initialization parameter TRANSACTIONS.
The Oracle server uses similar functionality internally in recursive transactions.
Transactions must be explicitly committed or rolled back or an error ORA-6519 is signaled when attempting to return from the autonomous block.
A deadlock situation may occur where a called and calling transaction deadlock; — this is not prevented, but is signaled by an error unique to this situation. The application developer is responsible for avoiding this situation.
原文链接：http://click.aliyun.com/m/26188/