RDBのisolation levelと排他制御について

Question

前提・実現したいこと

SprigBootを利用したアプリ開発での、実装規約を作成しています。
その中で、「@Transactional」のパラメータである「isolation」について、どういった場合に何を指定すべき悩んでおります。

発生している問題・エラーメッセージ

アプリケーションの排他制御の設計(楽観的排他制御、悲観的排他制御)と関係してくるかと思うのですが、どういった場合に何を指定すべきか悩んでおります。
「Isolation」でとりうる値は下記5つです。
・DEFAULT
・READ_COMMITTED
・READ_UNCOMMITTED
・REPEATABLE_READ
・SERIALIZABLE
DBにより、defaultの分離レベルが異なるというは認識しております。(READ_COMMITTEDかREPEATABLE_READ)
今まで、DBの分離レベルというのを意識して開発してこなかったので、どうすべきか悩んでおります。

補足情報（FW/ツールのバージョンなど）

SpringBootにて@Transactionalでトランザクション管理をしようとしております。

Answer 1

トランザクション分離レベルは、パフォーマンス要件とのバランスも考慮されますが、システムとしてデータ参照時にどれだけトランザクション間のズレを許容できるかも検討します。

Isolationについて平易にまとめられた内容
[RDBMS][SQL]トランザクション分離レベルについて極力分かりやすく解説
SQL

Springでの設定
Qiita:Springでトランザクション管理

Answer 2

以下参考
DBのトランザクションについて

Comments

[wi2yuki]

ご回答ありがとうございますmm
それを見ても？？って感じでした。。。

[sazi]

質問を見ても何を悩んでいるのかよく分かりません。
トランザクション分離レベルを理解した上で、楽観/悲観的排他を理解する必要があるんですが、同じレベルで考えようとしているように見受けられました。
なので、理解のための情報が不足しているのではないかと思いリンクを貼ったのです。

[wi2yuki]

＞トランザクション分離レベルを理解した上で、楽観/悲観的排他を理解する必要があるんですが、同じレベルで考えようとしているように見受けられました。
異なるレベルというのは認識しております。
そのレベルの整理が上手くいかず、悩んでおります。。。
トランザクション分離レベルと楽観・悲観的排他制御の整理と考え方がわからんのです。。。

[sazi]

分かないなら、その分からないところを質問しないと。
トランザクション分離レベルと楽観/悲観排他を切り離してなら、整理はついてるんでしょうか？

[wi2yuki]

>トランザクション分離レベルと楽観/悲観排他を切り離してなら、整理はついてるんでしょうか？
整理ができておらず悩んでいましたが、自分なりに考えた結果、なんとか考えをまとめることができました！
分離レベルを鑑みた上で、業務要件により悲観/楽観排他制御を変更するというのが良さげだという結論にいたりました。
また、分離レベルに関しては、「READ_COMMITED」か「REPEATABLE READ」がほとんどのDB製品でデフォルトであり、それ以外の分離レベルはビジネスレベルでは使用する機会がないと知りました。
「READ_COMMITED」か「REPEATABLE READ」の分離レベルの上で、楽観/悲観排他制御を業務要件で考えていく方針にしました。

[sazi]

READ COMMITED + for update + 楽観的排他
で殆ど事足ります。
for updateを起点となるテーブルを用意（トランザクション単位がレコード）して集中させれば、デッドロックに陥らずに済みます。

[wi2yuki]

ありがとうございます！！
大変勉強になりました(^^;)