4

私はJPAにまったく慣れておらず、JPA2.0のロックモードに関するこの記事を読んだので、LockModeType.OPTIMISTIC_FORCE_INCREMENTに関する質問が残りました。

これが記事の例の画像です：http：//i.stack.imgur.com/dFjhZ.jpg

これまでのところ、トランザクションT1での明示的な楽観的ロックは、エンティティAへの更新が、読み取られたばかりの別のエンティティBの状態に依存している場合にのみ必要であることを理解しています。

また、OPTIMISTIC_FORCE_INCREMENTを使用してロックすると、Bがそのバージョン属性を更新することを理解しています。これにより、Bを更新しようとし、ロックが発行される前に（つまり、古いバージョン値で）それを読み取ろうとするすべてのトランザクションでOptimisticLockExceptionが発生します。

私の質問は、Bのバージョンがインクリメントされた直後に別のトランザクションT2が開始され、Bが変更され、T1がコミットする前に終了した場合はどうなりますか？

私が理解している限り、T1はOptimisticLockExceptionを取得する必要があります。もしそうなら、それはT1の脆弱な時間枠をわずかに減らしたので、このロックのポイントは何ですか？つまり、T1が終了するまでBが変更されないようにする場合は、悲観的なロックが必要です。

これを私に明確にしてくれてありがとう:)

4

2 に答える 2

2

あなたの質問例は、これが「OPTIMISTIC」ロックと呼ばれる理由を強調しています。完璧ではありませんが、現実世界の多くの状況で十分であり、ハードロックよりもはるかに少ないリソース (時間を含む) を使用する場合.

このタイプのロックを使用すると、パフォーマンスと引き換えに使いやすさが向上し、ほとんどの場合トランザクションが機能することに賭けることになります。 '通知されます (例外がスローされます)。その後、一歩下がって「正しいことを行う」ことができます: 再試行、放棄、... ただし、例外を処理することを選択します。

悲観的ロックは、ある程度のロックが必要な高性能トランザクション システムには非常に不適切かもしれませんが、それらが衝突する可能性は最小限に抑えられます: xTunes の何百万ものユーザーの何人か (罪のない人を保護するために名前が変更されました..)"いつでも注文」(更新) していて、同じアカウントからすべて注文 (更新) しているのはいくつですか?

于 2013-03-09T00:49:22.097 に答える
1

B のバージョンがインクリメントされた直後に別のトランザクション T2 が開始され、B が変更され、T1 がコミットされる前に終了するとどうなりますか?

使用する RDBMS に関係なく、MVCC (Multi-Version Concurrency Control) または 2PL (Two-Phase Locking) を使用している場合でも、テーブルの行を変更すると、排他ロックが取得され、現在実行中のサーバーが実行されている場合にのみ解放されます。トランザクションが終了します (コミットまたはロールバック)。

したがって、B のバージョンをインクリメントすると、トランザクションをコミットするまで、他のトランザクションはそのレコードを変更できません。

と の違いにも言及する価値がOPTIMISTIC_FORCE_INCREMENTありPESIMISTIC_FORCE_INCREMENTます。OPTIMISTIC_FORCE_INCREMENTバージョンはトランザクションの終わりに向かって増加しますが、バージョンはPESIMISTIC_FORCE_INCREMENTすぐに上がります。

その特定のエンティティに激しい競合がある場合PESIMISTIC_FORCE_INCREMENT、ロックを取得すると、他のトランザクションがそのレコードを変更することは許可されず、楽観的なバージョンの不一致の失敗によりトランザクションがロールバックされないため、はるかに魅力的です。

于 2016-10-25T06:44:17.043 に答える