原創地址：http://www.cnblogs.com/jfzhu/p/4009918.html

轉載請注明出處

（一）為什么需要并發控制機制

并發控制機制是為了防止多個用戶同時更改同一條數據，也可以防止一個用戶在更改數據的同時造成另一個用戶看到”過期”的數據。下面看一個例子就明白了。

John和Marry有一個聯合銀行帳戶，帳戶的余額是$1000，John向帳戶里存入了$500，Marry取走了$500，如果沒有并發控制，John最后看到的余額是$1500，而Marry看到的帳戶余額是$500。

而如果使用了并發控制機制，在John讀取帳戶余額的時候，該帳戶就被鎖死了，Mary沒有辦法讀取或者修改該帳戶，直到John完成操作，把鎖釋放了。

（二）Optimistic Concurrency Control與Pessimistic Concurrency Control

有兩種并發控制機制，Optimistic concurrency control（樂觀？）和Pessimistic concurrency control（悲觀？），兩者之間的區別是：

Pessimistic concurrency control使用的機制是用戶A在讀取或修改某條記錄（rows）時，將該記錄鎖死，防止其他用戶同時讀取或修改同一條記錄。直到用戶A釋放掉鎖，其他用戶才可以對記錄讀取或修改，所以Pessimistic Lock的缺點是容易導致系統性能瓶頸。

Optimistic concurrency control在某條記錄被讀取時不會將記錄鎖死，只有當發現某條記錄被多個用戶同時修改的時候，其中一個用戶的修改可以被提交（commit），其他用戶會收到一個異常告知他們的修改沒有成功。

（三）SQL Server

SQL Server默認使用的是Pessimistic Concurrency Control，數據庫隔離級別（isolation level）是read committed。從SQL Server 2005開始，微軟增加了對Optimistic Concurrency Control的支持，兩個新的數據庫隔離級別，SNAPSHOT 和 READ COMMITTED SNAPSHOT isolation （RCSI）

SQL Server支持的隔離級別有如下幾個：

設置隔離級別可以用以下命令：

SET TRANSACTION ISOLATION LEVEL

查看隔離級別可以使用：

SELECT CASE transaction_isolation_level WHEN 0 THEN 'Unspecified' WHEN 1 THEN 'ReadUncommitted' WHEN 2 THEN 'ReadCommitted' WHEN 3 THEN 'Repeatable' WHEN 4 THEN 'Serializable' WHEN 5 THEN 'Snapshot' END AS TRANSACTION_ISOLATION_LEVEL FROM sys.dm_exec_sessions where session_id = @@SPID

或者

DBCC useroptions 

SQL Server默認使用的隔離級別是Read Committed。

（四）Dynamics CRM

Microsoft Dynamics CRM 2013 實施指南中提到：

運行使用 SQL Server（配置了已提交讀快照隔離 (RCSI)）的 Microsoft Dynamics CRM 將獲得商業上合理的支持。商業上合理的支持是指 Microsoft 客戶支持服務所提供的、不需要修改 Microsoft Dynamics CRM 代碼的所有合理的支持。—參見 《SQL Server deployment》

但是有一些文章并不建議使用RCSI，比如《The Potential Dangers of the Read Committed Snapshot Isolation Level》，所以我也不建議將數據庫隔離級別修改為RCSI。

（五）總結

本文介紹了為什么要使用并發控制機制，什么是Optimistic Concurrency Control和Pessimistic Concurrency Control，SQL Server所使用的并發控制機制，如何設置和查看數據庫的隔離級別，以及Dynamics CRM需要慎用RCSI。