在数据库的应用系统中,死锁是不可避免的。通过设置死锁的处理优先级方法,可以在数据库引擎中自动检测到死锁,对发生的死锁会话进行干预,从而达到解除死锁的目点,但在这种情况下,会话只能被动的等待数据库引擎的自我检查。
我们是否可以让会话自身也拥有处理死锁的主动权呢?这就是设置锁的超时时间。当一个会话与另一个会话冲突引阻塞时,如果等待的时间超过指定的值,则该会话自动取消,并释放数据库资源。这样,就达到了解决死锁的目的。
那么如何来查看锁的超时时间呢?利用@@lock_timeout函数即可: 可以看一下@@LOCK_TIMEOUT的语法与定义:
@@LOCK_TIMEOUT--返回当前会话的当前锁超时设置,单位为毫秒。
返回类型--integer
解释说明: SET LOCK_TIMEOUT 允许应用程序设置语句等待阻塞资源的最长时间。当一条语句已等待超过LOCK_TIMEOUT所设置的时间,则被锁住的语句将自动取消,并给应用程序返回一条错误信息。
比如,我们要查看一个会话的超时时间,可以利用以下sql来查看:
select @@LOCK_TIMEOUT
在没有设置过超时时间的情况下,该语句会返回结果-1,代表没有超时时间。
那么又如何设置超时时间呢?可以利用以下sql语句:
set lock_timeout <锁超时时间 >
注意: 1,锁超时时间是以毫秒为单位的。 2,设置的超时时间只对当次会话有效。 可以做一个简单的测试,在microsoft sql server management中打开一个查询窗口,执行
set lock_timeout 2600 select @@lock_timeout
可以看到返回结果为2600毫秒,然后再打开一个新的查询窗口(即一个新的会话),执行
select @@lock_timeout
返回结果为-1,可见前一个会话的设置对当前的会话无效。
如果将锁超时间设置为0,那么在发生资源锁定时,会话将不做任何等待,直接返回1222错误。
使用锁超时的不足之处: 如果我们有设置了锁超时时间,那么当会话等待时间达到超时时间时,就会直接返回1222错误,而且不会回滚或取消当前事务。需要我们在应用程序中截获1222错误,再作相关处理。如果我们在应用程序中未做任何处理,则事务会继续运行,从而导致程序的逻辑错误,因为前面有的语句可能根本没有执行或未执行完整。