問題タブ [pessimistic-locking]

ペシミスト ロック (InnoDB を使用) について理解を深めるために、Rails アプリケーションで次のコードを実行してみました。

それは実際に機能し、次のヒットでをaccount.balance含みます。ロックしないと、最後のスレッドが考慮され、結果は.7501500500

ロックするかどうかの違いを試すためのばかげたテストですか？悲観的ロックの原則は理解できたと思いますが、よくわかりません。

これらの同時実行制御の両方が平易な英語でどのように機能するかを理解しました。しかし、悲観的な制御がコードでどのように行われなければならないかということにもっと興味がありました。これが私が感じていることです。2 人のユーザーが wiki ドキュメントを更新しようとしているとします。

悲観的コントロール

ここでは、トランザクションを使用するように指示されています。

ただし、これは以前の更新を上書きする傾向があります。selectステートメントの後に書き込みが発生したかどうかを確認するために、トランザクション内で2回目のチェックが必要だと思います。そうであれば、ロールバックするかコミットします。私は正しいですか？

Rails Guide と他の多くのチュートリアルでは、ActiveRecord::StaleObjectError例外をレスキューし、楽観的ロックで再試行する方法を示しています。そして、悲観的なロックシナリオで同じことを行うことができるかどうかに興味があります。

どんな返信でも大歓迎です！:D

私は Spring-Data-Jpa を使用しており、データベース (Oracle) のロックを取得するために @Lock アノテーション (PESSIMISTIC_WRITE) を使用しています。次のシナリオがデータベースのデッドロックにつながる可能性があるかどうかを理解するのに助けが必要です。

1. トランザクション 1 (PROPAGATION_REQUIRES_NEW、ISOLATION_DEFAULT) は、Teacher テーブルなどに対してデータベース ロックを取得します (ID=1 の行に対してロックが取得されるとします)。会議などの子テーブルに新しいレコードを挿入しようとします。Teacher テーブルは更新されません。
2. トランザクション 1 の進行中。トランザクション 2 (PROPAGATION_REQUIRED、ISOLATION_DEFAULT) は、Teacher テーブル (id=1 の行) を更新しようとします。データベースのロックはかかりません。
3. ロックは ID 1 の行に引き継がれるため、トランザクション 2 はトランザクション 1 が乗り越えるのを待たなければなりません。

この状態がデータベースのデッドロックにつながる可能性はありますか?

ドキュメントによると、ロックが試行され、オブジェクトが既にロックされている場合、トランザクションはロールバックされず、LockTimeoutException がスローされます。

EntityManager の使用時に PessimisticLockException がスローされるのはどのような場合ですか?

Transaction Scope を使用して EF コンテキストの悲観的ロックを実装しようとしています。

モデル:

コントローラ：

現在、以下に説明する動作が機能するかどうかの承認を求めています。機能しない場合は、それを可能にするためのフィードバックやアドバイスをお待ちしております.

予想される動作:

3 つのスレッドがあると仮定しましょう: A - 最初に Join() を呼び出します。B - List() を呼び出します。C - Join() を 2 番目に呼び出します。

Room.Capacity は 1 です。

これは私が期待していることです: A は Join() を呼び出します。メソッドは、参加できるかどうかをチェックします。参加できるように見えるので、TransactionScope に入ります。この時点で、B は List() を呼び出します。A はまだ Join() を完了していないため、B はルームにユーザーがいないと考えています。ここで重要なことは、A がトランザクションを終了するまで B は待機せず、最後にコミットされた行のバージョンにアクセスすることです。現在、C は Join() を呼び出しています。A はまだトランザクションを処理しているため、C の最初のルーム テストは成功し、TransactionScope にも入ります。しかし、A はまだ完了していないため、C は今それを待つ必要があります。A がトランザクションを終了し、ルーム内のユーザー数が 1 になりました。A がトランザクションのロックを解除し、C がトランザクションに参加します。Room モデルを再度取得し、キャパシティをテストして参加できないことを確認し、例外をスローします。

私が壊れたかもしれないもの：

IsolationLevel.RepeatableRead についてはよくわかりません。ドキュメントでは、トランザクション中に揮発性データを読み取ることはできますが、変更することはできないと言われています。トランザクション中に新しいデータを追加できます。. 一方では、これにより List() メソッドが行をそのまま読み取れるようになり、TransactionScope が終了するのを待たないことを期待しています。また、テーブルではなく行のみをロックする必要があるため、新しい部屋を追加できます。しかし、Aがまだ実行されているときにCのTransactionScopeのロックをブロックしないのではないかと心配しています。そして最後に、「トランザクション中に揮発性データを読み取ることはできますが、変更することはできません」が TransactionScope にも当てはまるかどうかはわかりません。

要約すると、コードが期待どおりに動作するかどうか教えてください。そうでない場合は、それを達成するためにどのような調整を行う必要がありますか? 前もって感謝します。