2つのメソッドが公開されているWCFサービスがあります。
注：wcfサービスとSQLサーバーは同じマシンにデプロイされます。SQLサーバーには、従業員情報を保持するemployeeというテーブルが1つあります。
これで、クライアントがWebサービスを利用して従業員情報を照会、追加、更新、および削除できるデスクトップベースのアプリケーションを開発しました。
質問：
複数のクライアントが同時に従業員情報を更新したい場合、どのようにシナリオを処理できますか？SQLサーバー自体がデータベースロックを使用してこれを処理していますか？
最善のアプローチを教えてください！
一般に、切断された環境では、 /を使用した楽観的同時実行制御が推奨されるアプローチです。WCFは分散トランザクションをサポートしますが、これはシステムに長時間のブロッキングを導入するための優れた方法です。ほとんどのORMツールは、すぐに使用できる/サポートします。rowversiontimestamprowversiontimestamp
もちろん、サーバーでは、トランザクション（接続ベースまたはTransactionScope）を使用して個々のリポジトリメソッドを「ACID」にすることもできますが、ネットワーク上でのトランザクションはできるだけ避けたいと思います。
コメントを再確認してください。申し訳ありませんが、私は正直にそれらのコメントを見ませんでした。一度にたくさんのコメントを受け取った場合、stackoverflowではこれが簡単にならないことがあります。ここには2つの異なる概念があります。待機はブロックの兆候ですが、100のクライアントが同じレコードを更新している場合は、各トランザクション中にブロックすることが完全に適切です。簡単にするために、ボトルネック（追加の作業が必要）を示すことができない限り、更新操作に関するシリアル化可能なトランザクションから始めます（TransactionScopeデフォルトではこれを使用します）。そうすれば、ほとんどのシナリオで適切なブロッキング（ACIDなど）が得られます。
でも; 2番目の問題は同時実行性です。同じレコードに対して100個の更新を取得した場合、どちらを信頼するかをどのように判断しますか？ほとんどのシステムは、最初の更新を許可し、データに関する古い仮定に基づいて動作しているため、残りを破棄します。これがタイムスタンプ/行バージョンの出番です。UPDATEステートメントに「タイムスタンプ/行バージョンが一致する必要があります」を適用することにより、スナップショットを取得してから変更されていないデータのみを更新できるようにします。この目的のために、更新する興味深いデータと一緒に行バージョンを保持するのが一般的です。
もう1つの方法は、WCFサービスをシングルトン（InstanceContext.Single）としてインスタンス化できることです。これは、実行されているインスタンスが1つだけであることを意味します。次に、更新ロックの目的で単純なオブジェクトをメモリに保持し、そのオブジェクトに基づいて更新メソッドをロックすることができます。他のセッションから更新呼び出しが着信すると、ロックが解除されるまで待機する必要があります。
よろしく、スティーブ