Optimistic Concurrency VS. Pessimistic Concurrency Control

（一）为什么需要并发控制机制

并发控制机制是为了防止多个用户同时更改同一条数据，也可以防止一个用户在更改数据的同时造成另一个用户看到”过期”的数据。下面看一个例子就明白了。

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。

本文转自JF Zhu博客园博客，原文链接：   http://www.cnblogs.com/jfzhu/p/4009918.html ，如需转载请自行联系原作者