ADO.NET Entity Framework 中的乐观并发答案

【问题标题】：Optimistic concurrency in ADO.NET Entity FrameworkADO.NET Entity Framework 中的乐观并发
【发布时间】：2009-08-03 12:08:20
【问题描述】：

我发现 an MSDN article 描述了 EF 在保存更改时如何处理并发：

默认情况下 [...] 对象服务保存对象对数据库的更改不检查并发。为了可能会遇到的属性并发度高，我们建议实体属性为在概念层中定义为的一个属性 ConcurrencyMode="固定"

我有两个问题：

在我的模型中没有ConcurrencyMode="fixed" 的属性，我可以安全地假设如果在保存更改时抛出OptimisticConcurrencyException，那是因为实体不再存在于数据存储中，即它有被其他用户删除了，还是我遗漏了什么？

我想象 EF 执行一个看起来像这样的UPDATE-statement，在我看来，如果 ID = 1 的人不存在，只会导致抛出 OptimisticConcurrencyException：
```
 UPDATE Person SET FirstName = 'John' AND LastName = 'Smith' WHERE ID = 1
```
当使用ConcurrencyMode="fixed" 时，EF 在删除实体时是否也会检查并发性？换句话说，EF 是否会执行如下所示的DELETE-statement（不仅仅是WHERE-clause 中的主键）：
```
 DELETE FROM Person WHERE ID = 1 AND LastName = 'Doe'
```

【问题讨论】：

【解决方案1】：

好问题。

(1) 是的，但不幸的是，事情并没有这么简单。因为 EF (3.5) 有一个独立的关联模型，所以关联也被独立处理，即使您没有这么说，它也成为 UPDATES 和 DELETES 期间并发检查的一部分。

即当您更新 Person 时，您通常会看到如下所示的更新：

UPDATE Person SET Partner = NULL AND FirstName = 'John' AND LastName = 'Smith' 
WHERE ID = 1 AND Partner = 2

即Partner 是 FK 列。

如果您使用 FK 关联，这一切在 4.0 中都会发生变化，正如我们期望的大多数人一样。

(2) 对于 DELETE，删除期间检查任何 ConcurrencyMode = 'fixed' 属性。例外情况是当您有一个不接受该并发值的删除 SPROC。

希望对你有帮助

亚历克斯

【讨论】：