大量注文記録システムを構築しようとしています。次の 3 つのプライマリ テーブルがあります。 1. Orders 2. OrderDetails 3. OrderShipment
Shipment テーブルには、注文ごとに n レコードが含まれており、レコードの出荷エントリは、顧客が注文を受け入れる前に変更でき、その後は凍結されます。(ビジネス要件)
これは実際のシナリオでは発生しない可能性がありますが、負荷テスト中に System.Data.Linq.ChangeConflictException 例外が発生しています。送信をトランザクション内にラップすることも役に立ちません。更新操作の全期間にわたって LINQ に強制的に行をロックさせることはできませんか?
これを乗り越える他の方法はありますか？
同じデータの同時更新で真の問題が発生している場合は、操作全体をトランザクションで実行することを検討してください。つまり、データを取得してコミットすることです。get/update/commit を短時間のアトミック操作として扱う限り (つまり、途中でユーザー入力のために一時停止しない)、問題ありません。
特に、直列化可能な分離レベルでは、読み取りロックがオンになっているデータ (つまり、クエリしたもの) は誰も更新できません。唯一の問題は、異なるクエリが異なる順序でデータを読み取る場合、デッドロック シナリオにつながる可能性があることです。私の知る限り、LINQ-to-SQL に (UPDLOCK) ヒントを発行させる方法はありません。これは残念です。
シリアライズ可能な分離 (TransactionScope の既定値) として設定されている限り、TransactionScope または SqlTransaction のいずれかで実行できます。
この種の状況、つまり、複数のユーザーが同じレコード/顧客/注文などに変更を加えたい場合は、データベースロックを使用するよりも、アプリケーションロジックに「ロック」を組み込む方がよいでしょう。
DBロックを使用してデータの論理ロックを解決すると、新しい問題が山積みになります。より良い解決策は、注文/顧客などが[ユーザーによって]編集されていることを、ロックされるまでなどを示すことができる列やテーブルを用意することです。そのテーブル（または複数の列）を照会して、顧客かどうかを確認します。 / order / thingsは、別のユーザーに編集を許可する前に編集できます。
参照： http ：//forums.microsoft.com/MSDN/ShowPost.aspx？PostID = 3984968＆SiteID = 1
すべてをトランザクションとして実行するEntity Frameworkを調べることができます。Entity Framework についても興味深い 2 つのポッドキャストを次に示します。