数据库死锁:
不同session之间,因为等待对方释放资源,而导致死锁,这时候数据库会选择终止其中一个会话的sql,来解开死锁,最简单的条件是,
session A 等待 session B
session B 等待 session A,
这时候数据库会牺牲到其中的一个session,来释放资源,主流数据库都有自己的死锁检测机制

例子:
session 1:
SYS@oracle10g>delete from test_a;
已删除2行。
session 2:
SYS@oracle10g>delete from test_b;
已删除2行。

session 1:

SYS@oracle10g>delete from test_b;
delete from test_b
            *
第 1 行出现错误:
ORA-00060: 等待资源时检测到死锁

session 2:

SYS@oracle10g>delete from test_a;

这时候我们假设数据库不做自动去解开死锁,那么这2个session将一直阻塞对方,2个session谁也跑不下去.

回到主题:
我在标题里的死锁加上了引号,说明这个不是单纯的数据库死锁,但是数据库死锁,数据库自己会去牺牲其中的一个session,来解开死锁,但是我碰到的死锁是,"永远也跑不掉的死锁",除非人工去干预.

程序代码大概是这样的:

for(   )
{
  function() ;
  .......
}
这个方法是个同步方法,同时这个方法也是个操作数据库的方法.
我们假设这样一种情况:
进程a,进入循环后会调用到这个同步方法,对数据库做更改,假设这时候操作了记录A
这时候,进程b,也进入到循环,它也会调用到这个同步方法,假设b也操作到记录B
那么由于数据库的锁机制,进程b必然会去等待进程a,这就是我们常见的锁阻塞,
这时候进程a,还在循环里执行,进程a又会调用到这个同步方法,由于进程b一直操纵着
这个同步方法,所以这时候进程a必须等待进程b执行完这个方法,这时候就出现
进程B等待进程A释放数据库上的锁,进程A等待进程B释放线程锁,单独从数据库和程序
角度来看,都只是锁等待,而从系统角度上看,就是死锁,2个进程互相等待对方释放资源,
这时候因为程序和数据库谁也控制不了谁,所以就出现了2个进程都跑不下去的情况,只能
手工去杀掉一个进程,让另一个进程继续执行.

这是个典型的应用程序设计上的问题,因为数据库的锁机制我们无法控制,所以只能通过
程序上的改动来绕过这个问题

ITPub博客

另类"死锁"

最新文章