ADO.NET实体框架中的乐观并发

ber*_*hof 7 .net entity-framework optimistic-concurrency

我找到了一篇MSDN文章,描述了EF在保存更改时如何处理并发:

默认情况下,[...] Object Services将对象更改保存到数据库,而不检查并发性.对于可能经历高度并发性的属性,我们建议在概念层中使用ConcurrencyMode ="fixed"属性定义实体属性

我有两个问题:

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

    我想EF执行一个UPDATE看起来像这样的-statement,正如我所看到的那样,只有OptimisticConcurrencyException当ID = 1的Person不存在时才会抛出:

    UPDATE Person SET FirstName = 'John' AND LastName = 'Smith' WHERE ID = 1
    
    Run Code Online (Sandbox Code Playgroud)
  2. 使用时ConcurrencyMode="fixed",EF在删除实体时是否检查并发性?换句话说,EF是否会执行DELETE看起来像这样的-statement(不仅仅是-clause中的主键WHERE):

    DELETE FROM Person WHERE ID = 1 AND LastName = 'Doe'
    
    Run Code Online (Sandbox Code Playgroud)

Ale*_*mes 6

好问题.

(1)是的,但不幸的是,这并不是那么简单.因为EF(3.5)具有独立的关联模型,所以关联也是独立处理的,即使您没有这样说,它也会在UPDATES和DELETES期间成为并发检查的一部分.

即,当您更新Person时,您经常会看到如下所示的更新:

UPDATE Person SET Partner = NULL AND FirstName = 'John' AND LastName = 'Smith' 
WHERE ID = 1 AND Partner = 2
Run Code Online (Sandbox Code Playgroud)

即Partner是FK专栏.

如果您使用FK关联,这一切都会在4.0中发生变化,正如我们所期望的那样.

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

希望这可以帮助

亚历克斯