質問概要

JPA Persistenceのコンテキストの挙動とEntityManagerのロック機能に関して、
認識が合っているかについて確認したく、識者よりご回答いただければ幸いです。

以下記載があります。どうぞよろしくお願いいたします。

前提

APIを実装した同一モジュールを2台のサーバに配置してロードバランサで動作させています。

詳細

以下、上から順に処理が進んだものとしてご参照いただければ幸いです。

サーバ別のPersistence Contextの状態イメージ

step1.

一台目のサーバに対してアクセスがあり、
data1がPersistenceContextに保存されたとします。

サーバ1: PerCtx [data1] <-- Ctxに保存。
サーバ2: PerCtx [-----]

step2.

続けて保存されたdata1に対して悲観的READロックを掛けて成功します。

サーバ1: PerCtx [data1(非読取lock)]
サーバ2: PerCtx [-----]

step3.

その後、サーバ1が続けて処理している間に、サーバ2にもアクセスがあり、
同一データに対してロックを掛けようとしたとします。

サーバ1: PerCtx [data1(非読取lock)]
サーバ2: PerCtx [-----] <<- data1

想定

この時、私はサーバ2側は正しくサーバ1側のロック解放を待ってくれると想定しています。
しかし、別の人間からJPAはサーバのインスタンスが異なる場合に動作しないのではないか？
という意見があり、果たしてそうだったかと困惑しています。

※私は悲観的ロックが成功した時点で、該当データのレコードに対して
※SQLによるSELECT For UPDATEが掛かるため、サーバ2側はSELECTが出来なくなると思っています。

質問

Q1.
上記の流れについて、私の認識が間違っているでしょうか？
間違いがありましたらご指摘いただきたく。

Q2.
上記補足していただけるような書籍・URL等ありましたらご教示いただければ幸いです。

以上、よろしくお願いいたします。

行動規範の内容に同意します

回答1件

ベストアンサー

Q1

それほど自信をもって回答できないのですが、いくつかのプロジェクトでJPA(Hibernate) + Spring Dataを利用した経験上から、ご質問にある想定においてほぼ同じ意見です。
違う点は下記に引用させて頂いた文章の

※私は悲観的ロックが成功した時点で、該当データのレコードに対して
※SQLによるSELECT For UPDATEが掛かるため、サーバ2側はSELECTが出来なくなると思っています。

サーバ2側はSELECTが出来なくなるの部分は、私の認識では悲観的ロックが掛かっていた場合、SELECTは可能ですが**ロックの獲得は出来ない（ロックの獲得待ちになる）**というものです。

この点をMySQL 8.0で確認しました。
次のようにMySQL clientを2つ立ち上げ（それぞれをcli-A、cli-Bとします）、ロックを獲得してみます。

cli-A

2つ目のSQL(select ... for update)でロックします。

sql
1// 1)トランザクション開始
2> start transaction;
3Query OK, 0 rows affected (0.00 sec)
4
5// 2)ロック獲得
6> select * from memo where id = 1 for update;
71 row in set (0.00 sec)
8
9// 3)ロックしたデータを更新
10> update memo set title = 'trans1 update' where id = 1;
11Query OK, 1 row affected (0.00 sec)
12Rows matched: 1  Changed: 1  Warnings: 0
13

このままロックした状態で、cli-BからSQLを実行します。

cli-B

2つ目のselect文ではロックが掛かったデータを参照することは可能ですが
3つ目のselect ... for updateでロック獲得待ちになります。（タイムアウトで指定した時間以内にロックが獲得できない場合はタイムアウトします）

sql
1// 1)トランザクション開始
2> start transaction;
3Query OK, 0 rows affected (0.00 sec)
4
5// 2)ロックされているデータを検索
6> select * from memo where id = 1;
71 row in set (0.00 sec)
8
9// 3)ロック獲得 -> ロック獲得待ち
10> select * from memo where id = 1 for update;
11// タイムアウト
12ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

このロックの挙動は基本的にJPA(Hibernate)でも同様という認識でいます。
（ただMySQL clientと完全に同じ挙動かどうかは自信がありません。）

ちなみに、JPA(Hibernate)の悲観的ロックのLockModeTypeによって実行されるSQLが変わりますので、悲観的ロックといってもどちらのモードを使うかによって挙動がかわると思います。

LockModeType.PESSIMISTIC_READ -> select ... lock in share mode
LockModeType.PESSIMISTIC_WRITE -> select ... for update

Q2

期待されている情報源として、JPAやHibernate、EclipseLinkなどのORM、Spring Data、MyBatisなどのフレームワーク、ライブラリのリファレンスや、それらの開発者のブログ等の信頼性の高いものだと思いますが、残念ならがご期待に適う情報は持っていませんでした。

強いて挙げれば、下記のサイトになりますが、ご質問の内容に直接関係する内容はなかったように思います。

Hibernate ORM 5.2 Locking
https://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/chapters/locking/Locking.html

Pessimistic Locking in JPA
https://www.baeldung.com/jpa-pessimistic-locking

Understanding JDBC Internals & Timeout Configuration
https://www.cubrid.org/blog/understanding-jdbc-internals-and-timeout-configuration

以上、ご参考になれば幸いです。

投稿2018/08/11 16:32

rubytomato

総合スコア1752

sllmejacob

2018/08/13 01:58

ご返信が遅れました。ご回答ありがとうございます。後で気が付いたのですが、一部に誤記載がありました（悲観的READロックではなくWRITEロックが正しかった）が、rubytomato様に補足いただいた内容で認識が合ったと思っています。記載した通り、2サーバ間でレコードロックが掛かるかどうかを心配していたのですが、同一レコードのロック獲得処理があれば解放待ちしてくれそうということで、期待通りの挙動になってくれそうです。今回のケースは結構単純な例ではあると思うのですが、私の方で探してみてもなぜか例示やQA事項が無く、念のため根拠なり実装例なりを期待していたので、rubytomato様の回答非常にありがたく思います。ベストアンサー付けさせていただきます。ありがとうございました。

行動規範の内容に同意します