ユーザーがデータレコードを編集し、同時に別のユーザーも同じレコードを編集して両方を保存した場合。
1.)同時実行例外は常に1人のユーザーに対してのみ発生しますか?
実際には、最初の人が勝つことは論理的ですが、技術的な面で最初の人は誰ですか...両方のユーザーがこの種の例外を受け取る可能性はありますか?
2.)遅すぎて同時例外を取得している人は、アクセスできると思います
他のユーザーからの新しい更新されたデータレコードはい?
ユーザーがデータレコードを編集し、同時に別のユーザーも同じレコードを編集して両方を保存した場合。
1.)同時実行例外は常に1人のユーザーに対してのみ発生しますか?
実際には、最初の人が勝つことは論理的ですが、技術的な面で最初の人は誰ですか...両方のユーザーがこの種の例外を受け取る可能性はありますか?
2.)遅すぎて同時例外を取得している人は、アクセスできると思います
他のユーザーからの新しい更新されたデータレコードはい?
SQLRead committed
サーバーのデフォルトの分離レベル:
オブジェクトにアクセスするための同時要求が来ると、SQL サーバーはそれらのキューを作成し、それらを 1 つずつ処理します。2 番目のユーザーは、ユーザー 1 がタスクを完了するまで事前定義された時間待機し、その時間内にタスクを完了できない場合はエラーをスローします。この時間枠は、SQL サーバーと ADO.net で構成できます。
同時アクセスが必要かどうかは、すべてSQLサーバーで定義された分離レベルに依存します。
1) はい、そう思います。一方は常に他方よりも早くなります。他に方法はありません。したがって、1 つの更新は通常どおり機能し、もう 1 つの更新は同時実行例外をスローします。
これは、使用しているデータ アクセス方法に依存する可能性があり、そのような状況をよりエレガントに処理できるシステムが存在する可能性があります。しかし、意図的にその動作を構築することなく、両方のユーザーに同じ例外を与えるシステムがあるとは思えません。
Adam Houldsworth が言うように、これは自分でコーディングする方法にも依存する可能性があります。複数のユーザーが同じレコードを編集し始めていることを確認し、両方に例外をスローできます。しかし、それがあなたが実際に求めていることだとは思いません。もしそうなら; 誤解しました。
2) もちろんこれは可能ですが、アプリケーションに組み込むのはあなた次第です。同時実行例外をキャッチして、ユーザー B が更新しようとしていた編集フォームを更新するだけです。その後、再試行できます。一般的に言えば明らかに。あなたの状況の詳細はわかりません。