mysql - JPA PESSIMISTIC ロックから取得した DB 行の物理ロック

Question

JPA 2.1仕様によると...

ロック モードPESSIMISTIC_READ、PESSIMISTIC_WRITE、および PESSIMISTIC_FORCE_INCREMENTは、長期データベース ロックを即座に取得するために使用されます。

SELECT ... FOR UPDATEどのロックモードが使用されていても、悲観的ロックは常にデータベースで SQL をトリガーすると思います。それについて3つの質問があります：

1. 仮定は正しいですか、それとも正しい場合、この規則からの例外はありますか?
2. 行がSELECT ... FOR UPDATEロックされているとします。ロックされた行は、それをロックしたトランザクション以外のトランザクションによって更新できませんか?
3. ロックは、トランザクションに対してコミットまたはロールバックを実行することで解放できます。アプリケーション (および行をロックしたトランザクション) が、トランザクションでコミットまたはロールバックを実行せずに突然終了した場合、ロックはどうなりますか?

Answer 1

質問 1 と 2 については、あなたの仮定は正しいです。

1. はい -SELECT ... FOR UPDATEほとんどのデータベースと JPA 実装はこのタイプのロックのみをサポートするため、悲観的ロックは通常 を使用します。この場合、READ ブロックと WRITE ブロックの間に違いはなく、JPA 仕様では、両方が WRITE ロックとして動作する限り許可されます。

2. はい - ロックされた行は他​​のトランザクションによって変更できません。WRITE ロックの場合 (およびほとんどの場合、READ ロックの場合も - 1 の回答を参照)、ロックされた行は、ロックが解放されるまで読み取ることもできません。同じテーブル内のロックされていない他の行は、自由に読み取りおよび変更できることに注意してください。

質問3にも答えるには：

3. はい - コミットまたはロールバックの場合、ロックは解放されます。ただし、エラーが発生したり、接続が切断されたり、トランザクションに時間がかかりすぎたりすると、ロールバックも自動的に行われます。そのため、アプリケーションが終了すると、ロールバックがすぐにトリガーされます。そうでない場合は、一定のタイムアウト (通常は 5 分) 後にロールバックされます。