質問

MSDNの記事 EFが変更を保存するときに並行性をどのように処理するかを説明します:

  

デフォルトでは[...] Object Servicesはオブジェクトを保存します   データベースへの変更なし   並行性の確認。にとって   発生する可能性のあるプロパティ   高度な並行性、我々   エンティティプロパティが   概念層で定義された   の属性   ConcurrencyMode ="修正済み"

2つの質問があります:

  1. モデルに ConcurrencyMode =" fixed" のプロパティがない場合、保存時に OptimisticConcurrencyException がスローされると想定しても安全です変更されたのは、エンティティがデータストアに存在しなくなったためです。つまり、別のユーザーによって削除されたか、何か不足していますか?

    EFは次のような UPDATE ステートメントを実行することを想像します。これにより、私が見るように、 OptimisticConcurrencyException がスローされるのは、 ID = 1は存在しません:

    UPDATE Person SET FirstName = 'John' AND LastName = 'Smith' WHERE ID = 1
    
  2. ConcurrencyMode =" fixed" を使用する場合、EFはエンティティを削除するときに同時実行性もチェックしますか?言い換えると、EFは次のような DELETE -文を実行します( WHERE -clauseの主キーだけではありません):

    DELETE FROM Person WHERE ID = 1 AND LastName = 'Doe'
    
役に立ちましたか?

解決

良い質問です。

(1)はい、しかし残念ながら、これはそれほど単純ではありません。 EF(3.5)には独立したアソシエーションモデルがあるため、アソシエーションも独立して扱われ、あなたがそう言わなかったとしても、UPDATESおよびDELETES中の同時実行性チェックの一部になります。

i.e。 Personを更新すると、次のような更新が頻繁に表示されます。

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

i.e。パートナーはFKコラムです。

FKアソシエーションを使用する場合、ほとんどの人もそうであるように、これは4.0ですべて変わります。

(2)DELETEの場合、削除中にConcurrencyMode = 'fixed'プロパティがチェックされます。例外は、その並行性の値を受け入れない削除用のSPROCがある場合です。

これが役立つことを願って

アレックス

scroll top