🚦 Spring Framework 講座【第27回】データの衝突を防ぐ！〜トランザクションの隔離レベルと並行処理〜

前回、トランザクション（Transaction）を使うことで、複数のデータベース操作を一つのまとまり（ACID特性）として扱い、処理の信頼性を保証することを学びました。

しかし、実際の業務システムでは、複数のユーザーやプロセスが同時に（並行して）データベースにアクセスします。この同時アクセスを適切に制御しないと、**データの競合（コンフリクト）**が発生し、トランザクションの重要な特性である「隔離性（Isolation）」が損なわれてしまいます。

今回は、このデータの競合を防ぐための「隔離レベル（Isolation Level）」という概念について深く学びます。

1. 隔離性（Isolation）が破られたときに起こる問題

トランザクションの隔離性が不十分な場合、データベースの処理中に、以下のような一貫性のないデータを参照してしまう問題（ダーティリードなど）が発生する可能性があります。

1-1. 隔離レベルで防ぐべき3つの現象

現象名	概要	発生条件
ダーティリード（Dirty Read）	未コミットの変更データ（Rollbackされるかもしれないデータ）を読み取ってしまう現象。	最も危険性が高い。
ノンリピータブルリード（Non-Repeatable Read）	同じトランザクション内で同じデータを2回読み取ったとき、間に他のトランザクションがコミットしたことで、異なる結果を読み取ってしまう現象。	データが消滅したり増えたりはしない。
ファントムリード（Phantom Read）	同じトランザクション内で特定の検索条件で2回検索したとき、間に他のトランザクションがレコードを挿入/削除したことで、行数（件数）が異なってしまう現象。	存在しなかったデータが「幻（ファントム）」のように現れる。

2. トランザクションの隔離レベル

これらの問題を防ぐために、DBには「どこまで厳密に隔離するか」という基準として4つの隔離レベルが用意されています。隔離レベルが厳しくなるほど、データの一貫性は高まりますが、同時実行性が下がり、性能が低下します。

隔離レベル	ダーティリード	ノンリピータブルリード	ファントムリード	補足
READ UNCOMMITTED	発生する	発生する	発生する	最も隔離性が低い。ほとんど使われない。
READ COMMITTED	防ぐ	発生する	発生する	多くのDBのデフォルト設定。コミットされたデータのみ参照。
REPEATABLE READ	防ぐ	防ぐ	発生する	MySQLのデフォルト。トランザクション中は常に同じデータを読む。
SERIALIZABLE	防ぐ	防ぐ	防ぐ	最も隔離性が高い。並行処理ができず、性能が極端に低下する。

ポイント: ほとんどの業務システムでは、READ COMMITTED または REPEATABLE READ が使われます。SERIALIZABLEは、極めて高いデータ整合性が求められるケース（例：会計処理）でのみ検討されます。

3. Springでの隔離レベルの設定

Springの @Transactional アノテーションを使うことで、メソッド単位で簡単に隔離レベルを設定できます。

デフォルトでは、データベース側の設定（例：PostgreSQLはREAD COMMITTED、MySQLはREPEATABLE READ）が適用されますが、特定の業務処理で隔離レベルを上げたい場合に利用します。

Java

import org.springframework.transaction.annotation.Isolation;

@Service
public class OrderService {

    // 顧客の残高チェックなど、特に高い整合性が求められるメソッド
    // トランザクションが終了するまで、他の変更から完全に隔離される（REPEATABLE READ）
    @Transactional(isolation = Isolation.REPEATABLE_READ) 
    public void executeHighConsistencyProcess(Long userId) {
        // ... 処理
    }

    // 読み取り専用で、最新のコミット済みデータで十分なメソッド（デフォルトのREAD COMMITTEDで十分）
    @Transactional(readOnly = true, isolation = Isolation.READ_COMMITTED) 
    public List<Order> findRecentOrders() {
        // ... 処理
    }
}

4. まとめ：適切な隔離レベルの選択

隔離レベルは、データ整合性とシステム性能のトレードオフです。

性能優先: READ COMMITTED（ほとんどの標準的な処理）
整合性優先: REPEATABLE READ（データの変更を含む、厳密な処理）

全ての処理に最高レベルの隔離性（SERIALIZABLE）を適用することは、システムが遅くなりすぎるため現実的ではありません。業務要件に応じて最低限必要な隔離レベルを選択することが、パフォーマンスチューニングの鍵となります。

✅ 本日のまとめ

並行処理によって、ダーティリード、ノンリピータブルリード、ファントムリードといったデータ不整合が発生する可能性がある。
隔離レベルは、これらの不整合をどこまで許容するかを設定する基準であり、「SERIALIZABLE」が最も厳しく、「READ UNCOMMITTED」が最も緩い。
READ COMMITTEDとREPEATABLE READが、実用上最も多く使われるレベルである。
Springでは、@Transactional(isolation = Isolation.レベル名) を使って、メソッド単位で隔離レベルを宣言的に設定できる。
隔離レベルを厳しくすると、データの整合性は高まるが、同時実行性が下がり、性能が低下する。