データベースの最初のアプローチを使用して、データベース内の対応する行が別のアプリケーション/ユーザー/セッションによって既に更新されている (古い) エンティティを更新しようとするたびに、アプリケーションが同時実行例外をスローするようにします。
.Net 4.5 で Entity Framework 5 を使用しています。対応するテーブルには、行のバージョンを維持するための Timestamp 列があります。
データベースの最初のアプローチを使用して、データベース内の対応する行が別のアプリケーション/ユーザー/セッションによって既に更新されている (古い) エンティティを更新しようとするたびに、アプリケーションが同時実行例外をスローするようにします。
.Net 4.5 で Entity Framework 5 を使用しています。対応するテーブルには、行のバージョンを維持するための Timestamp 列があります。
Entity Framework 5 の同時実行とタイムスタンプについて説明しているここと Web 上の多くの投稿を確認した結果、モデルが既存のデータベースから生成された場合、基本的に同時実行例外を取得することは不可能であるという結論に達しました。
1 つの回避策は、.edmx ファイルで生成されたエンティティを変更し、エンティティのタイムスタンプ プロパティの「同時実行モード」を「固定」に設定することです。残念ながら、モデルがデータベースから繰り返し再生成されると、この変更が失われる可能性があります。
ただし、トリッキーな回避策が 1 つあります。
Repeatable Read 以上の分離レベルでトランザクション スコープを初期化する
行のタイムスタンプを取得する
新しいタイムスタンプと古いタイムスタンプを比較する
等しくない --> 例外
等しい --> トランザクションをコミットします
分離レベルは、推論の同時変更を防ぐために重要です。
PS: Erikset のソリューションは、モデル ファイルの再生成を克服するのに問題ないようです。
行が影響を受けていない場合、EF は同時実行の競合を検出します。次に、ストアド プロシージャを使用して削除および更新する場合は、where 句にタイムスタンプ値を手動で追加できます。
UPDATE | DELETE ... WHERE PKfield = PkValue and Rowversionfield = rowVersionValue
次に、行が他の誰かによって削除または変更された場合、Sql ステートメントは 0 行に影響し、EF はそれを同時実行の競合として解釈します。