什么是sql server 2005使用的默认并发控制?

时间:2011-06-24 08:53:08

标签: sql-server concurrency

我对这个问题的答案相互矛盾。我得到一个答案,SQL Server 2005使用悲观并发控制作为默认here,但这个答案得到驳斥here(请参阅第二个回复)SQL Server没有任何默认的并发控制,它只是给出了实现乐观或悲观并发控制的机制。我应该相信谁,有些人可以通过权威来源证实他们的答案。

感谢您的期待。

2 个答案:

答案 0 :(得分:2)

SQL Server默认使用悲观并发

这在官方MS文件中明确说明......

更改为SQL Server 2005+的乐观,您需要启用快照隔离

答案 1 :(得分:2)

我不认为SQL Server的默认行为正是“悲观的并发控制”。让我们考虑以下简单示例,该示例在默认隔离级别READ COMMITTED:

下运行
-- Connection one

BEGIN TRANSACTION;

SELECT * FROM Schedule 
WHERE ScheduledTime BETWEEN '20110624 06:30:00' 
AND '20110624 11:30' ;

-- Connection two
UPDATE Schedule 
SET Priority = 'High'
WHERE ScheduledTime ='20110624 08:45:00'
-- nothing prevent this update from completing, 
-- so this is not exactly pessimistic

-- Connection one
DELETE FROM Schedule 
WHERE ScheduledTime ='20110624 08:45:00' ;
COMMIT ;
-- nothing prevents us from deleting 
-- the modified row

关于gbn发布的链接中的以下语句:“从历史上看,SQL Server中服务器级别的并发控制模型一直是悲观的,并且基于锁定。”,我对它的含义的理解是这样的:2005年之前只提供了实现悲观并发的工具。然而,我们仍然需要提高隔离级别来实现悲观的并发性,它默认不会发生,也不会发生。

当然,我可能错了。我已经发送了MSDN文章的作者Kalen Delaney,这个帖子的链接。希望她能找几分钟发表评论。

编辑:这是MSDN定义:“悲观并发控制在事务持续期间锁定资源。除非发生死锁,否则确保事务成功完成。”显然,默认情况下不会发生这种情况,正如我在我的示例中所示 - 共享锁在读取行后被释放。