悲观并发：比如有两个用户A,B，同时登录系统修改一个文档，如果A先进入修改，则系统会把该文档锁住，B就没办法打开了，只有等A修改完，完全退出的时候B才能进入修改。

乐观并发：同上面的例子，A,B两个用户同时登录，如果A先进入修改紧跟着B也进入了。A修改文档的同时B也在修改。如果在A保存之后B再保存他的修改，此时系统检测到数据库中文档记录与B刚进入时不一致，B保存时会抛出异常，修改失败。

乐观并发的基本出发点是：当保存数据的时候抱着一种乐观的态度，不期望发生并发冲突，即使万一发生并发冲突，也能捕捉到冲突异常，然后根据策略解决冲突，而解决冲突的方式一般分为Client wins（以后操作者为赢） 和 Store wins（以先存储的数据为赢）。

　Resolving optimistic concurrency exceptions with Reload

　　使用Reload数据作为解决乐观并发异常的策略之一，我在这里就讲数据Reload这一种策略就好了，除了Reload外，还有其他几种冲突解决策略，详见参考文献中EF官方团队博客。

using (var context = new UnicornsContext())
{
    bool saveFailed;
    do
    {
        saveFailed = false;
        var unicorn = context.Unicorns.Find(1);
        unicorn.Name = "tom";
        try
        {
            context.SaveChanges();
        }
        catch (DbUpdateConcurrencyException ex)
        {
            saveFailed = true;
            // Update the values of the entity that failed to save 
            // from the store
            ex.Entries.Single().Reload();
        }
    } while (saveFailed);
}

四、SqlProfiler看原理

　　完成以上步骤后，您的程序就具备了乐观并发处理的能力了，但是，其中的原理是什么呢？从SqlProfiler监控结果来看，EF是将并发模式设置为Fixed的字段放在where子句里，后操作会因为取不到相应的记录而更新失败，打个比方说，当两个用户同时对同一条记录（ID=1，Count=10）进行读、写操作的时候，A、B同时读取记录的时候，Count都等于10，A用户先进行Update减1操作，此时（ID=1，Count=9），而此时B用户稍微晚一点点再进行Update操作的时候，因为Count已经被A修改成9了，已经不存在（ID=1，Count=10）的记录了，所以B最终执行影响行数为0，EntityFramework抛出并发异常：

如：我们给Count属性的并发模式设置成Fixed的话，那生成的SQL语句如下：

exec sp_executesql N‘update [dbo].[OrderLog]
set [Count] = @0
where (([ID] = @1) and ([Count] = @2))‘,N‘@0 int,@1 int,@2 int‘,@0=78,@1=1,@2=9 

当EntityFramework执行更新操如果影响行数为0，就会抛出异常，相关源代码如下所示：

参考文献