C# Entity Framework并发处理

在软件开发过程中，并发控制是确保及时纠正由并发操作导致的错误的一种机制。从 ADO.NET 到 LINQ to SQL 再到如今的 ADO.NET Entity Framework，.NET 都为并发控制提供好良好的支持方案。
并发处理方式一般分为乐观必并发与悲观必并发两种，本文将为大家介绍 Entity Framework 、 LINQ to SQL 中的并发处理方式。在本文最后，将提供一个了可参考的方案，结合事务与并发控制确保安全的数据交换机制。

目录

一、并发处理的定义

二、模型属性的并发处理选项

三、Entity Framewrok 悲观并发

四、Entity Framework 乐观并发

五、回顾 LINQ to SQL 并发处理的方式

六、结合事务处理并发冲突

一、并发处理的定义

在软件开发过程中，当多个用户同时修改一条数据记录时，系统需要预先制定对并发的处理模式。并发处理模式主要分为两种：
第一种模式称为悲观式并发，即当一个用户已经在修改某条记录时，系统将拒绝其他用户同时修改此记录。
第二种模式称为乐观式并发，即系统允许多个用户同时修改同一条记录，系统会预先定义由数据并发所引起的并发异常处理模式，去处理修改后可能发生的冲突。常用的乐观性并发处理方法有以下几种：

1. 保留最后修改的值。
2. 保留最初修改的值。
3. 合并多次修改的值。

相对于LINQ TO SQL 中的并发处理方式，Entity Framework 中的并发处理方式实现了不少的简化，下面为大家一一介绍。

二、模型属性的并发处理选项

在System.Data.Metadata.Edm 命名空间中，存在ConcurencyMode 枚举，用于指定概念模型中的属性的并发选项。ConcurencyMode有两个成员

当模型属性为默认值 None 时，系统不会对此模型属性进行检测，当同一个时间对此属性进行修改时，系统会以数据合并方式处理输入的属性值。
当模型属性为Fixed 时，系统会对此模型属性进行检测，当同一个时间对属性进行修改时，系统就会激发OptimisticConcurrencyException 异常。
开发人员可以为对象的每个属性定义不同的 ConcurencyMode 选项，选项可以在*.csdl 找看到：

三、Entity Framework 悲观并发

在一般的开发过程中，最常用的是悲观并发处理。.NET 提供了Lock、Monitor、Interlocked 等多个锁定数据的方式，它可以保证同一个表里的对象不会同时被多个客户进行修改，避免了系统数据出现逻辑性的错误。
由于本篇文章主要介绍并发处理方式，关于锁的介绍，请参考http://www.cnblogs.com/leslies2/archive/2012/02/08/2320914.html#t8

使用悲观并发虽然能有效避免数据发生逻辑性的错误，但使用 lock 等方式锁定 Update 方法的操作，在用户同时更新同一数据表的数据，操作就会被延时或禁止。在千万级 PV 的大型网络系统当中使用悲观并发，有可能降低了系统的效率，此时可以考虑使用乐观并发处理。

四、Entity Framework 乐观并发

为了解决悲观并发所带来的问题，ADO.NET Entity Framework 提供了更为高效的乐观并发处理方式。相对于LINT to SQL , ADO.NET Entity Framework 简化了乐观并发的处理方式，它可以灵活使用合并数据、保留初次输入数据、保留最新输入数据等方式处理并发冲突。

4.1 以合并方式处理并发数据

当模型属性的 ConcurencyMode 为默认值 None ，一旦同一个对象属性同时被修改，系统将以合并数据的方式处理并发冲突，这也是 Entity Framework 处理并发冲突的默认方式。合并处理方式如下：当同一时间针对同一个对象属性作出修改，系统将保存最新输入的属性值。当同一时间对同一对象的不同属性作出修改，系统将保存已被修改的属性值。下面用两个例子作出说明：

4.1.1 同时更新数据

在系统输入下面代码，先获取数据库中的 Id 为24的对象 Person，使用Display方法在数据修改前显示对象的最初值。然后使用异步方法分两次调用Update方法，同时更新Person对象的相关属性，第一次更新对象的 FirstName 属性，第二次更新对象的 SecondName、Age 两个属性。最后，在使用SaveChanges保存更新后，显示数据更新后的信息。

根据操作结果可以看到，在Entity Framework的默认环境情况下，系统会使用合并方式处理并发，把输入数据的所有修改值都保存到当前上下文当中，并同时修改数据库当中的值。

4.1.2 删除与更新操作同时运行

Entity Framework 能以完善的机制灵活处理同时更新同一对象的操作，但一旦删除操作与更新操作同时运行时，就可能存在逻辑性的异常。例如：两个客户端同时加载了同一个对象，第一个客户端更新了数据后，把数据再次提交。但在提交前，第二个客户端已经把数据库中的已有数据删除。此时，上下文中的对象处于不同的状态底下，将会引发 OptimisticConcurrencyException 异常。
遇到此异常时，可以用 try（OptimisticConcurrencyException）{...} catch {...} 方式捕获异常，然后使用 ObjectStateManager.ChangeObjectState 方法更改对象的 EntityState 属性。把EntityState 更改为 Added ，被删除的数据便会被再次加载。若把 EntityState 更改为 Detached 时，数据便会被顺利删除。下面把对象的 EntityState 属性更改为 Added 作为例子。

观察运行测试结果，当运行 Delete 方法，对象已经在数据库中被删除，对象的EntityState处于 Detached 状态。此时使用 SaveChanges 保存更新数据时，引发了OptimisticConcurrencyException 异常。在捕获异常，把对象状态更改为 Added ，再使用SaveChanges保存数据，数据就能顺利地保存到数据库中。但值得留意，因为对象是在删除后重新加载的，所以对象的 Id 也会被同步更新。

以合并数据的方式处理并发冲突固然方便快节，但在业务逻辑较为复杂的系统下并不适合使用此处理方式。比如在常见的Order、OrderItem的表格中，OrderItem 的单价，数量会直接影响Order的总体价格，这样使用合并数据的方式处理并发，有可能引起逻辑性的错误。此时，应该考虑以其他方式处理并发冲突。

4.2 当发生数据并发时，保留最新输入的数据

要验证输入对象的属性，必须先把该属性的 ConcurencyMode 设置为 Fixed，这样系统就会实时检测对象属性的输入值 。
当该属性被同时更新，系统便会激发 OptimisticConcurrencyException 异常。捕获该异常后，可以使用 ObjectContext.Refresh (RefreshMode,object) 刷新上下文中该对象的状态，当 RefreshMode 为 ClientWins 时，系统将会保持上下文中的现在有数据，即保留最新输入的对象值。此时再使用ObjectContext.SaveChanges, 系统就会把最新输入的对象值加入数据库当中。

在下面的例子当，系统启动前先把 Person 的 FirstName、SecondName 两个属性的 ConcurencyMode 属性设置为Fixed，使系统能监视这两个属性的更改。所输入的数据只在FirstName、SecondName 两个值中作出修改。在数据提交前先以 DisplayProperty 方法显示数据库最初的数据属性，在数据初次更新后再次调用 DisplayProperty 显示更新后的数据属性。在第二次更新数据时，将引发OptimisticConcurrencyException 异常，此时把引发异常的对象属性再次显示出来。对异常进行处理后，显示数据库中最终的对象值。

观察测试结果，可见当RefreshMode状态为ClientWins时，系统将会保存上下文当中的对象属性，使用此方法可以在发生并发异常时保持最新输入的对象属性。

4.3 当发生数据并发时，保留最初输入的数据

把对象属性的 ConcurencyMode 设置为 Fixed 后，同时更新该属性，将会激发 OptimisticConcurrencyException 异常。此时使用 ObjectContext.Refresh (RefreshMode,object) 刷新上下文中该对象的状态，当 RefreshMode 为 StoreWins 时，系统就会把数据源中的数据代替上下文中的数据。
因为初次调用 SaveChanges，数据可以成功保存到数据库。但是在 ObjectContext 并未释放时，再次使用 SaveChanges 异步更新数据，就会引发OptimisticConcurrencyException 并发异常。当 RefreshMode 为 StoreWins 时，系统就会保留初次输入的数据属性。
此例子与上面的例子十分相似，只是把 RefreshMode 改为 StoreWins 而已。在业务逻辑较为复杂的的系统当中，建议使用此方式处理并发异常。在保留最初输入的数据修改属性后，把属性返还给客户，让客户进行对比后再决定下一步的处理方式。

观察测试结果，可见当 RefreshMode 状态为 StoreWins 时，系统将会以数据源中的数据代替上下文当中的对象属性。在业务逻辑较为复杂的的系统当中，建议使用此方式处理并发异常。

回到目录

五、回顾 LINQ to SQL 并发处理的方式

Entity Framework 当中简化了并发处理的方式，然而温故而知新，LINQ to SQL 中并发处理所使用的方式也值得回顾一下。下面将与大家一起回顾一下 LINQ to SQL 当中并发处理的方式。
与 Entity Framework 相似，LINQ to SQL 中表格的每个列都为可以设定不同处理方式，属性 UpdateCheck (更新检查) 的默认值为 Always，即系统会在默认情况下检查属性的并发状态。若把属性改为 WhenChanged，即当该属性发生改变时，系统才会对其进行检测。若把属性改为 Nerver , 这时系统将不会对此属性进行检查，总是接受最新一次的输入值。

处理 LINQ to SQL 并发，最为重要的是以下两个方法：

DataContext.SubmitChanges(ConflictMode)
DataContext.ChangeConflicts.ResolveAll(RefreshMode);

SubmitChanges 将对检索到的对象所做的更改发送到基础数据库，并通过 ConflictMode 指定并发冲突时要采取的操作 。当选择 ConflictMode.FailOnFirstConflict 时，若检测到第一个并发冲突错误时，系统会立即停止对更新数据库的尝试。当选择 Conflict.ContinueOnConflict 时，系统会尝试运行对数据库的所有更新。

ConfilctMode成员图

ResolveAll 能使用指定策略解决集合中的所有冲突，当选择 RefreshMode.KeepChanges 时，系统会强制 Refresh 方法保持当前上下文的数据值。当选择RefreshMode.OverwriteCurrentValues, 系统会用数据库的值覆盖当前上下文中的数据值。当选择 RefreshMode.KeepCurrentValues, 系统会把当前上下文的更新值与数据库中的值进行合并处理。

RefreshMode 成员图

当 Person 表格的多个列的 UpdateCheck 属性都为默认值 Always 时，多个客户同时更新此数据表，最后使用 DataContext.SubmitChanges(ConflictMode.ContinuOnConflict) 同时提交数据时，系统就会释放出 ChangeConflictException 异常。系统可以以捕获此并发异常后，再决定采取 KeepChanges、KeepCurrentValues、OverwriteCurrentValues 等方式处理数据。

例子当中使用 RefreshMode.KeepChanges 的方式处理并发，系统会保存最新输入的数据。观察测试结果，当系统发生第一次更新时，数据成功保存到数据库当中。在 DataContext 未释放前，再次输入数据，引发了ChangeConflictException异常。在捕获此并发异常后，系统以 RefreshMode.KeepChanges 方式进行处理，最后新输入的数据成功保存到数据库当中。

回到目录

六、结合事务处理并发冲突

Entity Framework 中已经有比较完善的机制处理并发，但使用乐观性并发处理数据，一旦多个客户端同时更新同一张表格的同一个对象时，将会激发 OptimisticConcurrencyException 异常，系统必须预先定制好处理方案对此并发异常进行处理。结合事务使用乐观性并发共同处理数据，是一个比较高效的数据管理方式。事务能对数据的更新进行检测，一旦发现异常，便会实现回滚。本文会使用常用的隐式事务 TransactionScope 作为例子进行介绍，对事务的详细介绍，可以参考 “C#综合揭秘——细说事务”。
使用乐观性并发，在发生并发异常时保留最初输入值，并利用事务，对引起 OptimisticConcurrencyException 异常的修改进行回滚，最后把引起异常的数据与数据库中的已有数据以页面或者窗口的形式显示给客户进行对比，这是最为常用的数据处理方式之一。这样既可以保持系统高效运行，也可以避免系统数据出现逻辑性的错误。
下面举个例子，对此方法进行说明。首先把 Person 对象的 FirstName、SecondName 属性的 ConcurencyMode 设置为 Fixed 后，系统会同时更新 Id 等于 52 的 Person 对象这两个属性，更新的操作会以 TransactionScope 进行监控。在同时更新属性时，系统会释放出OptimisticConcurrencyException 异常，系统捕获此异常后会显示出数据库中的数据与客户输入的数据让客户进行对比，并同时实现回滚。

观察测试结果，当系统发生并发异常时，数据库只会保留首次输入的更新值。值得注意的是：使用此数据处理方式与悲观并发方式最大区别在于，传统的悲观并发处理方式不允许同一时刻有多个客户端处理同一个数据表中的相同对象，但因为客观因数的影响，系统难以仔细辨认客户同时进行修改的是否同一个数据项，所以基本的做法是使用锁把更新对象进行锁定。但如此一来，无论客户同时更新的是否同一个数据项，操作都将会被延时或禁止。换句话说，无论需要更新的是相同对象还是不同对象，客户端都不能同时更新同一个数据表。若使用此乐观并发方式，系统允许多个客户端同时处理同一个数据表。如果所处理的是数据表中的不同对象，操作可以顺利地进行而不会相互影响。如果所处理的是数据表中的相同对象，操作将会保存第一次输入的对象值。

回到目录

总结

并发话题与线程、进程等其他话题有所不同，它并没有复杂的类和方法。处理并发来来去去都是简单的几行代码，它所重视的是并发异常发生后所带来的后果与处理方式。与中国传统的太极相似，并发只重其意，不重其招，只要深入地了解其过程，考虑其可能带来的问题后，你便可以对其收发自如。 
对并发的处理应该针对特定的问题，分别对待。到最后你可能发现，原来微软早已为你定制好处理的方式，可能 “回到原点” 什么都不做就是最好的处理方式。