問題タブ [read-committed]

私のグループと私は、主題が通貨制御である学校のプロジェクトのために映画予約システムを作成しました。これは、プレゼンテーション層が mvc プロジェクトで構成されている n 層アーキテクチャの c# およびエンティティ フレームワークで作成されています。

「予約する座席を選択する」段階で悲観的ロック (IsolationLevel.ReadCommited) を使用することを選択しました。これにより、誰かが空席があるかどうかを確認している間、および座席が予約に追加されたときにデータベースがロックされます。たとえば、オプティミスティック同時実行がオプションであったかどうか、もしそうならそれがどのように機能するかを現在探しています。

データベース ダイアグラムの図を次に示します。

特定のショーをクリックすると、空の予約が自動的に作成され、利用可能かどうかに関係なく、座席と情報を含む画面 (シネマ ホール) が作成されます。

画面（映画館）にリンクされた座席のリストを作成する方法は次のとおりです。

このメソッドから、複数の座席を一度に選択できるチェックボックスとして、画面 (シネマ ホール) が構成されます。選択した座席は、TryBookSeats メソッドへの AJAX 呼び出しを介して、reservationId と共に送信されます。このメソッドは、最初に誰かがあなたの座席を予約しようとしたかどうかを確認し、そうでない場合は、ReservationSeats テーブルに配置して予約します。

TryBookSeats メソッドは次のとおりです。

ご覧のとおり、isolationLevel ReadCommited を使用しました。これは悲観的ロックであると推測され、ReservationSeats にシートを追加する際に競合が発生しないようにします。

また、ロックするテーブルは 1 つだけなので、デッドロックは発生しないと思います。

オプティミスティック カレントが機能する 1 つの方法は、データベースの更新をコミットする前に、レコードを取得してからデータベースが変更されていないかどうかを確認することだと理解しています。座席(およびreservationId)をreservationSeatsテーブルに追加する前に、それらがショーのために予約されているかどうかを確認することを選択できたでしょうか。

「radacct」という名前の mysql innodb テーブルがあります。このテーブルには、アップロード、ダウンロード、アカウント ID などのユーザーのインターネット使用記録が含まれています (以下のテーブル スキーマ)。テーブルは、radacctルーターから送信されたデータでランダムな間隔で更新されます。また、このテーブルを使用してインターネット ユーザーの合計帯域幅を計算します。帯域幅計算クエリ (選択) には約 3 ～ 4 秒かかります。ロックをめぐって競合するルーターから帯域幅計算クエリと更新クエリが同時に実行されると、問題が発生します。これは RepeatableRead ロック (テーブル レベルのロック) が原因で、ここで ReadCommitted 分離を使用する方が良いですか?

帯域計算クエリ

で見られる挿入/更新クエリmysql> show full processlist;

良い一日。postgresで分離レベルをいじっていたREAD COMMITTEDところ、公式ドキュメントに従わない奇妙な動作が見つかりました。テーブルaccount(id int,name text,amount int)と 2 つの行があるとします。

ここで、2 つの READ COMMITTED トランザクションを開始します。最初のものは次のクエリを実行します

そして、2番目はこのクエリを実行します

最初のトランザクションがまだコミットされていないため、現在はロックされています。したがって、2 番目のトランザクションでは、合計金額が 1000 以上の各口座に 50 を追加する必要があります。Bob には 2 つの口座 (800+200) があるため、各口座に 50 を追加する必要があります。ただし、最初のトランザクションがコミットさCOMMIT; --1れ、Bob の合計は 900 になり、Documentation Read commit transaction willによると、

コマンドの検索条件 (WHERE 句) が再評価され、更新されたバージョンの行がまだ検索条件に一致するかどうかが確認されます。その場合、2 番目の updater は、行の更新されたバージョンを使用して操作を続行します。

私の知る限り、2 番目のトランザクションは where 条件を再評価し、ボブのアカウントをスキップします。ただし、2 番目のトランザクションがコミットされると、最終的な行は次のようになります

これは、2 番目のトランザクションが検索条件を再評価せず、条件に一致しない場合でも行に更新を適用したことを意味します。なぜそれが起こるのですか？ドキュメントで何かを見逃していましたか?