2、数据库本身加锁机制的实现方法不同,各数据库系统也会产生其特殊的死锁情况。如在Sybase SQL Server 11 中,最小锁为 2K一页的加锁方法,而非行级锁。如果某张表的记录数少且记录的长度较短(即记录密度高,如应用系统中的系统配置表或系统参数表就属于此类表),被访问的频率高,就容易在该页上产生死锁。
表现一:
一个用户 A 访问表 A(锁住了表 A),然后又访问表 B。另一个用户 B 访问表 B(锁住了表 B),
然后企图访问表 A。这时用户 A 由于用户 B 已经锁住表 B,它必须等待用户 B 释放表 B,
才能继续,同样用户 B 要等用户 A 释放表 A 才能继续操作,这样就造成了死锁。
解决方法:
这种死锁是由于程序的 BUG 产生的,需调整程序对数据库层的实现逻辑。仔细分析程序的逻辑:
(1)尽量避免同时锁定两个资源。
(2)必须同时锁定两个资源时,要保证在任何时刻都应该按照相同的顺序来锁定资源。
表现二:
用户 A 读一条纪录,然后修改该条纪录,同时用户 B 也修改该条纪录。这里用户 A 的事务里锁的性质由共享锁企图上升到独占锁 (for update),而用户 B 里的独占锁由于 A 有共享锁存在所以必须等 A 释放掉共享锁,而 A 由于 B 的独占锁而无法上升的独占锁也就不可能释
放共享锁,于是出现了死锁。这种死锁比较隐蔽,但其实在稍大点的项目中经常发生。
解决方法:
让用户 A 的事务(即先读后写类型的操作),在 select 时就是用 update lock。
语法如下:select * from table1 with(updlock) where ….
上一篇:python, perl
下一篇:异常ip