独自の通貨を使用する小さなウェブショップを想像してみてください。
データベースには、購入可能なアイテムのテーブルがあります。各アイテムの数には限りがあります。この制限は、このテーブルの列に整数として格納されます。
また、ユーザーの現金口座の表がありますが、口座ごとに現在の残高が保存されます。
たとえば、2人のユーザーが同時に購入を行い、1つのアイテムしか入手できない場合、競合状態のために、両方のユーザーが支払いを行っても1人だけがアイテムを受け取る可能性があります。
保存時に例外をスローするエンティティフレームワークに依存せずに、このような競合状態をどのように解決できますか？
利用可能なアイテムの数と購入者の口座残高が正しく更新されていることを確認するにはどうすればよいですか？
これは、Entity Frameworkに固有の問題ではなく、ほぼすべてのショップシナリオに当てはまります。ポリシーの問題になります。2人の顧客が同じアイテムを購入しないようにする唯一の方法は、アイテムをカートに追加するとき、またはチェックアウトプロセスを開始するときに、そのアイテムに一時的なロックをかけることを許可することです。コンサートのチケットやフライトの販売方法と似ています。このロックは、購入が設定された時間内に完了しない場合に期限切れになり、他の顧客が購入できるようにアイテムが解放されます。
eコマースの設定では、これは適切ではありません。なぜなら、人々はカートにアイテムを追加してチェックアウトしないか、追加のアイテムを選択するために余分な時間を費やす可能性があるからです。これは、販売中のアイテムがあるが、チェックアウトを計画していない誰かのカートに入っているために購入できないというシナリオにつながる可能性があります。代わりに、重複注文は許可されますが、支払いは通常、事前承認され、発送または注文確認時に完了するだけなので、2番目の顧客がすべての詳細を入力して[購入]を押しても、カードに請求されることはありません。アイテムは出荷できません。
You can implement checks at different stages during the Checkout process to ensure the items in the cart are still available, or at the simplest level, leave it for the final "Pay Now" button on the last page. Ultimately though, this just reduces the potential for the race condition, rather than eliminating it.