4

Accounts次のようなテーブルがあります。

AccountID   AccountName   AccountTotalMoney
-------------------------------------------
  1           Steven           600
  3           Scott            800

ただし、ユーザーは次のように行レコードを同時に更新できます。

User A:UPDATE Accounts SET AccountTotalMoney=700 WHERE AccountID=1;
User B:UPDATE Accounts SET AccountTotalMoney=900 WHERE AccountID=1;
User C:UPDATE Accounts SET AccountTotalMoney=1000 WHERE AccountID=1;
.
.
.

したがって、複数のユーザーが同じレコードを同時に更新することを防ぎたいと思います。次々と。

私はこの面で初心者です。英語が下手でごめんなさい。前もって感謝します！

4

2 に答える 2

6

多くの可能性があります。

[意見：ほとんどのWebアプリケーションは楽観的同時実行処理を行うと思います]：

楽観的同時実行処理に関する優れたチュートリアルは、http： //msdn.microsoft.com/en-us/library/bb404102.aspxにあります。

小さな要約：

同様に、2人のユーザーがページにアクセスしている場合、1人のユーザーが別のユーザーによって削除されたときに、レコードを更新している最中の可能性があります。または、ユーザーがページを読み込んでから[削除]ボタンをクリックするまでの間に、別のユーザーがそのレコードのコンテンツを変更した可能性があります。

利用可能な3つの同時実行制御戦略があります。

  • 何もしない-同時ユーザーが同じレコードを変更している場合は、最後のコミットを優先させます（デフォルトの動作）。•</li>
  • 楽観的同時実行性-同時実行性の競合が時々発生する可能性がありますが、ほとんどの場合、そのような競合は発生しないと想定します。したがって、競合が発生した場合は、別のユーザーが同じデータを変更したため、変更を保存できないことをユーザーに通知してください。
  • 悲観的な同時実行性-同時実行性の競合は一般的であり、ユーザーは、別のユーザーの同時アクティビティのために変更が保存されなかったと言われることを容認しないと想定します。したがって、1人のユーザーがレコードの更新を開始するときは、そのレコードをロックして、ユーザーが変更をコミットするまで、他のユーザーがそのレコードを編集または削除できないようにします。
于 2012-11-17T16:39:40.200 に答える
5

Pleunsの答えは良いと思います。より具体的には：

  • 楽観的な一致-行が変更されていないことを確認し、変更されている場合はロールバックを実行します。例：更新のたびに増加するバージョン列を追加し、更新を行うときにバージョン番号が同じであることを確認します。

  • 悲観的な並行性：より複雑です。トランザクションレベルのIsolationLevel.Serializableを使用して行をロックしますが、トランザクションが複数のWebリクエストにまたがる場合、これはお勧めできません。

于 2012-11-17T20:10:14.810 に答える