JPAの同時実行制御とロック20140518 #ccc_r15 #jjug_ccc

Copyright UCHIDA HUMAN DEVELOPMENT all rights reserved. 1
JJUG CCC 2014 Spring
Java EE 7対応！
JPAの同時実行制御とロック
2014/05/18
(株)ウチダ人材開発センタ多田真敏

このセッションについて
Twitterハッシュタグ : #ccc_r15
JPAの同時実行制御とロックについて、基礎から
詳しく説明します
同時実行制御とロックにおいて、JPA実装と
DBMSを変えたときの、挙動の違いや注意点を
説明します

アジェンダ
まずは自己紹介
同時実行制御とロックとは？
JPAにおける同時実行制御とロック
今回のサンプルプログラム
EclipseLink×MySQLの場合
EclipseLink×PostgreSQLの場合
Hibernate×MySQLの場合
Hibernate×PostgreSQLの場合
まとめ

まずは自己紹介

あんた、誰？
IT研修インストラクター、
社会人7年目。三十路。
専門はJava、.NET、ネット
ワーク、業務知識など。
中小企業診断士、SJC-
WC、応用情報技術者。

Twitter・ブログ
Twitter : @suke_masa
ブログ : Java EE 事始め！
http://masatoshitada.hatenadiary.jp/

同時実行制御とロックとは？

ロックとは？
empno ename sal
101 Nishida 500000
102 Nohira 285000
103 Kiyama 245000
T1 T2
複数のトランザクションから同時に実行された
とき、データの不整合が起こらないように行・表
・DBにロックをかける、DBMSの機能
○ ×

ロックなしの場合に起こる不整合
empno ename sal
101 Nishida 500000
102 Nohira 285000
103 Kiyama 245000
本当は520000
にならないと
おかしい！
2つのトランザクションか
ら同時に、empno=101
のsalを10000プラスする
① T1：101のsalを検索
（500000）
② T2：101のsalを検索
（500000）
③ T1：salを①+10000に更
新（510000）
④ T2：salを②+10000に更
新（510000）

READロックとWRITEロック
① READロック（共有ロック）
他のトランザクションはREADロックは取得できるが
、WRITEロックは取得できない
② WRITEロック（占有ロック、排他ロック）
他のトランザクションはREADロックもWRITEロック
も取得できない
先のトランザクション
READロック WRITEロック
後のトランザ
クション
READロック ○ ×
WRITEロック × ×

JPAにおける
同時実行制御とロック

楽観的ロックと悲観的ロック
楽観的ロック（OPTIMISTIC）
更新対象の行に対して、他のトランザクションからの更新
は無いという前提に立つ
パフォーマンスは悲観的ロックと比較して高い
悲観的ロック（PESSIMISTIC）
更新対象の行に対してロックをかけ、他のトランザクショ
ンからの更新をDBMSが防ぐ
パフォーマンスは楽観的ロックと比較して低い
楽観的ロック → DBMSのロック機能を利用しない
悲観的ロック → DBMSのロック機能を利用する

バージョニング
「バージョン」を表す列を対象テーブルに追加
エンティティのバージョンフィールドには@Version
アノテーションを付加
バージョンの型はint（Integer）、short（Short）、long
（Long）、java.sql.Timestampが使用可能
更新時にバージョンの値が更新（インクリメントなど
）される

LockModeType
ロックモード説明
OPTIMISTIC 楽観的ロック
OPTIMISTIC_FORCE_
INCREMENT
楽観的ロック。バージョンの値をインクリメ
ントする
PESSIMISTIC_READ 悲観的ロック。READロックを取得する
PESSIMISTIC_WRITE 悲観的ロック。WRITEロックを取得する
PESSIMISTIC_FORCE
_INCREMENT
悲観的ロック。WRITEロックを取得し、
バージョンの値をインクリメントする
NONE ロックしない（デフォルト）
※READ・WRITEは非推奨

LockModeTypeの指定方法
EntityManagerインターフェイス
<T> T find(Class<T> entityClass, Object
primaryKey, LockModeType lockMode)
void lock(Object entity, LockModeType lockMode)
void refresh(Object entity, LockModeType lockMode)
Query（TypedQuery）インターフェイス
Query setLockMode(LockModeType lockMode)
NamedQueryアノテーション
lockmode属性

金魚本では・・・
「4.5 同時実行」は6ページしかない
悲観的ロックについては0.5ページ程度
Java EE 5までは楽観的ロックしかなかった

参考資料
Java EE 7 Tutorial
42. Controlling Concurrent Access to
Entity Data With Rocking
JSR-338 Java Persistence 2.1
3.4 Locking and Concurrency

SPECIAL THANKS!!
O社認定講師＆データベーススペシャリストの
Y部長
外語大卒の後輩Kちゃん

今回のサンプルプログラム

実験環境
JPA実装
EclipseLink 2.5.2-M1
Hibernate Entity Manager 4.3.1.Final
DBMS
PostgreSQL 8.4.19
MySQL 5.6.16
その他
Windows 7 SP1(x64)
JDK 7u45
Eclipse 4.3.1
2×2
＝4通り

使用するテーブル
empno（PK） ename sal version
101 Nishida 500000 1
102 Nohira 285000 1
103 Kiyama 245000 1
emp2
empno=101のレコードを検索後、
そのレコードのsalを10000プラスする処理を、
2スレッドから同時実行
バージョン列

エンティティクラス
@Entity
public class Emp2 implements Serializable {
@Id
private Integer empno;
private String ename;
private Integer sal;
@Version
private Integer version;
// setter/getter, equals(), hashCode(), toString()
}
version列と
対応するフィールド

スレッドクラス
public class UpdateThread extends Thread {
@Override
public void run() {
String threadName = Thread.currentThread().getName();
EntityManagerFactory factory =
Persistence.createEntityManagerFactory("emp");
EntityManager manager = factory.createEntityManager();
EntityTransaction tx = manager.getTransaction();
tx.begin();
Emp2 emp = manager.find(Emp2.class, 101, LockModeType.NONE);
int sal = emp.getSal();
System.out.println(threadName + " 検索直後 " + emp);
try {
Thread.sleep(1000);
} catch (InterruptedException e) { e.printStackTrace(); }
ここでLockModeType
を指定

try {
emp.setSal(sal + 10000);
System.out.println(threadName + " flush直前 " + emp);
manager.flush();
System.out.println(threadName + " flush直後 " + emp);
tx.commit();
System.out.println(threadName + " commit.");
System.out.println(threadName + " commit直後 " + emp);
} catch (Exception e) {
System.out.println(threadName
+ " 例外発生:" + e.getClass().getName());
e.printStackTrace();
tx.rollback();
System.out.println(threadName + " rollback.");
}

System.out.println(threadName + " 終了 " + emp);
manager.close();
factory.close();
}
}

メインクラス
public class Main {
public static void main(String[] args) {
Thread thread1 = new UpdateThread();
thread1.setName("T1");
Thread thread2 = new UpdateThread();
thread2.setName("T2");
thread1.start();
thread2.start();
}
}
マルチスレッドで
同時実行

EclipseLink×MySQLの場合

NONE
ロックしない（デフォルト）
バージョニングは不要なので、@Versionをコメン
トアウト
@Entity
・・・
// @Version コメントアウト
・・・
}

NONEの実行ログ
[EL Fine]: sql: SELECT EMPNO, ENAME, SAL, VERSION FROM EMP2 WHERE (EMPNO = ?)
bind => [101]
bind => [101]
T1 検索直後 Emp2 [empno=101, ename=Nishida, sal=500000, version=1]
T1 flush直前 Emp2 [empno=101, ename=Nishida, sal=510000, version=1]
[EL Fine]: sql: UPDATE EMP2 SET SAL = ? WHERE (EMPNO = ?) bind => [510000, 101]
T1 flush直後 Emp2 [empno=101, ename=Nishida, sal=510000, version=1]
T1 commit.
T1 commit直後 Emp2 [empno=101, ename=Nishida, sal=510000, version=1]
T1 終了 Emp2 [empno=101, ename=Nishida, sal=510000, version=1]
T2 commit.

実行の様子
① T1が検索→sal=500000
② T2が検索→sal=500000
③ T1がsal=500000+10000で更新
④ T2がsal=500000+10000で更新
salは最終的に510000になる

OPTIMISTIC
楽観的ロック
バージョニング必須
バージョンが無い場合はPersistenceException
@Entity
・・・
@Version // 必須
・・・
}

OPTIMISTICの実行ログ
bind => [101]
bind => [101]
[EL Fine]: sql: UPDATE EMP2 SET SAL = ?, VERSION = ? WHERE ((EMPNO = ?) AND
(VERSION = ?)) bind => [510000, 2, 101, 1]
(VERSION = ?)) bind => [510000, 2, 101, 1]
T1 commit.
T2 例外発生:javax.persistence.OptimisticLockException
T2 rollback.
（以下、スタックトレース）

実行の様子
① T1が検索→sal=500000, version=1
② T2が検索→sal=500000, version=1
③ T1がsal=500000+10000, version=1+1
で更新→コミット
④ T2がsal=500000+10000, version=1+1
で更新
→バージョンの値が既に変更されているため、
OptimisticLockExceptionが発生してロー
ルバック

実行後のバージョン値
ロールバックされたエンティティも、バージョン値
がインクリメントされる
T1 commit.
T1 commit直後 Emp2 [empno=101, ename=Nishida,
sal=510000, version=2]
T1 終了 Emp2 [empno=101, ename=Nishida, sal=510000,
version=2]
T2 rollback.
version=2]

バージョン値変更の検知方法
UPDATE文のWHERE句に主キーとバージョン列
を指定している
→バージョン値が既に変更されていた場合、
更新行数はゼロになる
[EL Fine]: sql: UPDATE EMP2 SET SAL = ?, VERSION = ?
WHERE ((EMPNO = ?) AND (VERSION = ?))
bind => [510000, 2, 101, 1]

OPTIMISTIC_FORCE_INCREMENT
楽観的ロック。バージョン値を強制的にインクリメ
ントする
EclipseLinkの場合、挙動はOPTIMISTICと全く
同じ

OPTIMISTIC_FORCE_INCREMENTの実行ログ
bind => [101]
(VERSION = ?)) bind => [510000, 2, 101, 1]
(VERSION = ?)) bind => [510000, 2, 101, 1]
T2 commit.
T1 rollback.

PESSIMISTIC_READ
悲観的ロック。READロックを取得
→EclipseLinkではSELECT FOR UPDATE文が
実行され、WRITEロックを取得する
バージョニング不要
@Entity
・・・
// @Version コメントアウト
・・・
}

PESSIMISTIC_READの実行ログ
FOR UPDATE bind => [101]
T1 commit.
T2 commit.

実行の様子
① T1が検索、WRTIEロックを取得
→sal=500000
② T2が検索しようとするが、T1がWRITEロックを取
得しているので、DB内の待ち行列に入る
③ T1がsal=500000+10000で更新
→コミットしたらロック解放
④ T2が待ち行列から出て検索、WRITEロックを取得
→sal=510000
⑤ T2がsal=510000+10000で更新

SQLログと実際の実行順序は違う
SQLログは、JPAがDBMSに発行した「つもり」の
SQLが表示される
実際には、発行されてもDBMS内の待ち行列に
入っている場合がある
[EL Fine]: sql: SELECT EMPNO, ENAME, SAL, VERSION FROM EMP2
WHERE (EMPNO = ?) FOR UPDATE bind => [101]
[EL Fine]: sql: SELECT EMPNO, ENAME, SAL, VERSION FROM EMP2
WHERE (EMPNO = ?) FOR UPDATE bind => [101]
・・・
・・・

PESSIMISTIC_WRITE
悲観的ロック。WRITEロックを取得
→EclipseLinkではPESSIMISTIC_READと
挙動は同じ
バージョニング不要

PESSIMISTIC_WRITEの実行ログ
T2 commit.
T1 commit.

PESSIMISTIC_FORCE_INCREMENT
悲観的ロック。バージョン値を強制的にインクリメ
ントする
チュートリアルにはWRITEロックかREADロック
か記述されていない
→JSRには「exclusive lock（＝WRITEロック）」
と書いてある

PESSIMISTIC_FORCE_INCREMENTの実行ログ
[EL Fine]: sql:SELECT EMPNO, ENAME, SAL, VERSION FROM EMP2 WHERE (EMPNO = ?) FOR
UPDATE bind => [101]
(VERSION = ?)) bind => [510000, 2, 101, 1]
T1 commit.
(VERSION = ?)) bind => [520000, 3, 101, 2]
T2 commit.

実行の様子
① T1が検索、WRTIEロックを取得
→sal=500000, version = 1
② T2が検索しようとするが、T1がWRITEロックを取
得しているので、DB内の待ち行列に入る
③ T1がsal=500000+10000, version=1+1で更新
④ T2が待ち行列から出て検索、WRITEロックを取得
→sal=510000, version=2
⑤ T2がsal=510000+10000, version=2+1で更新

EclipseLink×PostgreSQL
の場合

EclipseLink×MySQLと挙動は同じ
以下、ログのみ記載

NONEの実行ログ
bind => [101]
bind => [101]
T2 commit.
T1 commit.

bind => [101]
bind => [101]
(VERSION = ?)) bind => [510000, 2, 101, 1]
(VERSION = ?)) bind => [510000, 2, 101, 1]
T1 commit.
T2 rollback.
（以下、スタックトレース）

bind => [101]
bind => [101]
(VERSION = ?)) bind => [510000, 2, 101, 1]
(VERSION = ?)) bind => [510000, 2, 101, 1]
T1 commit.
T2 rollback.

T2 commit.
T1 commit.

T1 commit.
T2 commit.

(VERSION = ?)) bind => [510000, 2, 101, 1]
T2 commit.
(VERSION = ?)) bind => [520000, 3, 101, 2]
T1 commit.

Hibernate×MySQLの場合

NONE
発行されるSQLが微妙に異なるが、最終結果は
EclipseLinkと同じ

NONEの実行ログ
Hibernate: select emp2x0_.empno as empno1_0_0_, emp2x0_.ename as ename2_0_0_,
emp2x0_.sal as sal3_0_0_, emp2x0_.version as version4_0_0_ from Emp2 emp2x0_ where
emp2x0_.empno=?
emp2x0_.empno=?
Hibernate: update Emp2 set ename=?, sal=?, version=? where empno=?
T2 commit.
T1 commit.

OPTIMISTIC
ロールバックされたエンティティのバージョンはイ
ンクリメントされない

emp2x0_.empno=?
emp2x0_.empno=?
Hibernate: update Emp2 set ename=?, sal=?, version=? where empno=? and version=?
Hibernate: select version from Emp2 where empno =?
T1 commit.
T2 rollback.

ロールバックされたエンティティは、バージョン値
がインクリメントされない
T1 commit.
version=2]
T2 rollback.
version=1]

謎のSELECT文
T1がcommit時に発行している
→コミット前に、他のトランザクションからバージ
ョンが変更されていないかどうかを確かめるため
と思われる
T1 flush直後 Emp2 [empno=101, ename=Nishida,

OPTIMISTIC_FORCE_INCREMENT
flush時とcommit時の2回、バージョンがインクリ
メントされる
「謎のSELECT文」によるバージョン確認は無い

emp2x0_.empno=?
emp2x0_.empno=?
Hibernate: update Emp2 set version=? where empno=? and version=?
T2 commit.
T1 rollback.

flush時・commit時の2回、バージョンがインクリメントされ
る
T2 flush直前 Emp2 [empno=101, ename=Nishida,
Hibernate: update Emp2 set ename=?, sal=?, version=?
where empno=? and version=?
T2 flush直後 Emp2 [empno=101, ename=Nishida,
Hibernate: update Emp2 set version=? where empno=? and
version=?
T2 commit.

PESSIMISTIC_READ
SELECT・・・LOCK IN SHARE MODE文が実行さ
れ、READロックが取得される
→T1とT2が互いにロック解放待ちとなり、
デッドロック発生
→片方はロールバックされ、
もう片方のみがコミットされる

emp2x0_.empno=? lock in share mode
emp2x0_.empno=? lock in share mode
ERROR: Deadlock found when trying to get lock; try restarting transaction
T1 commit.
T2 例外発生:javax.persistence.PersistenceException
T2 rollback.

PESSIMISTIC_WRITE
SELECT FOR UPDATE文が実行され、WRITEロ
ックが取得される
→片方のトランザクションがコミット・ロック解放
後、もう片方のトランザクションも実行される

emp2x0_.empno=? for update
T1 commit.
T2 commit.

SELECT FOR UPDATE文が実行され、WRITEロ
ックが取得される
→片方のトランザクションがコミット・ロック解放
後、もう片方のトランザクションも実行される
OPTIMISTIC_FORCE_INCREMENTと同様、
flush時・commit時の2回、バージョンがインクリ
メントされる

T1 commit.
T2 commit.

Hibernate×PostgreSQLの場合

Hibernate×PostgreSQL
PESSIMISTIC_FORCE_INCREMENTのみ、
MySQLの場合と挙動が異なる
READロックはSELECT FOR SHARE文
上記以外は同じなので、ログのみ記載

NONEの実行ログ
emp2x0_.empno=?
emp2x0_.empno=?
T1 commit.
T2 commit.

emp2x0_.empno=?
emp2x0_.empno=?
T1 commit.
T2 rollback.

emp2x0_.empno=? for share
emp2x0_.empno=? for share
ERROR: ERROR: deadlock detected
T2 例外発生:javax.persistence.PersistenceException
T2 rollback.
T1 commit.

T1 commit.
T2 commit.

SELECT FOR UPDATE文にNOWAITオプション
が付加される
→後からのトランザクションは、待つことができな
いため例外発生
NOWAITオプションはMySQLには無い

emp2x0_.empno=? for update nowait
ERROR: ERROR: could not obtain lock on row in relation "emp2"
emp2x0_.empno=? for update nowait
T1 commit.

まとめ

まとめ
ロックモード相違点
OPTIMISTIC ・EclipseLinkでは、ロールバックされたエン
ティティのバージョン値もインクリメントされる
OPTIMISTIC_FORC
E_INCREMENT
・Hibernateでは、flush時とcommit時の2回、
バージョンがインクリメントされる
PESSIMISTIC_REA
D
・EclipseLinkでは、READロックではなく
WRITEロックになる
PESSIMISTIC_FOR
CE_INCREMENT
・Hibernateでは、flush時とcommit時の2回、
バージョンがインクリメントされる
・Hibernate×PostgreSQLでは、SELECT
FOR UPDATE文にNOWAITオプションが付加

開発時の注意
必ずSQLログを出力して、一通りの挙動を確認し
ておきましょう！
JPAのSQLログの順番は、実際にDB内で実行さ
れる順番とは異なる場合があるので、注意しま
しょう！

今回、入れられなかった内容
悲観的ロックのタイムアウト
javax.persistence.lock.timeout
悲観的ロックのスコープ
javax.persistence.lock.scope

技術の普及＝教育の普及
教育の
普及
技術の
普及

JPAの同時実行制御とロック20140518 #ccc_r15 #jjug_ccc

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to JPAの同時実行制御とロック20140518 #ccc_r15 #jjug_ccc

Similar to JPAの同時実行制御とロック20140518 #ccc_r15 #jjug_ccc (20)

More from Masatoshi Tada

More from Masatoshi Tada (10)

JPAの同時実行制御とロック20140518 #ccc_r15 #jjug_ccc