Springの楽観ロックと悲観ロックを完全解説！@VersionとLockModeTypeの使い分け入門

1. 楽観ロックとは？@Versionを使った競合防止

「1. 楽観ロックとは？@Versionを使った競合防止」の重要ポイントを、初心者の方にも分かりやすく簡潔に解説します。

1. 楽観ロックとは？@Versionを使った競合防止

楽観ロック（オプティミスティック・ロック）とは、データの更新時に「おそらく他の人は同時に更新しないだろう」と前向きに考えて処理を進める仕組みです。データベースのテーブルを長時間占有（ロック）しないため、システムの処理速度を落としにくいのが大きなメリットです。

Spring Data JPAでは、エンティティのフィールドに@Versionアノテーションを付与するだけで、この高度な排他制御を自動化できます。具体的には、データ取得時のバージョン番号と更新実行時のバージョン番号を比較し、もし数値が異なれば「誰かが先に更新した」と判断してエラーを発生させます。

@Entity
public class Product {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    private int stock;

    // このアノテーションが重要！
    @Version
    private Long version;

    // getter/setterは省略
}

上記のコードのように、versionという項目を追加して@Versionを付けるだけです。これにより、データが更新されるたびに数値が 1, 2, 3... と自動でカウントアップされます。

もし同時に二人が同じデータを編集しようとしても、後から保存ボタンを押した人には例外（OptimisticLockingFailureException）が投げられ、不正な上書き（いわゆる「ロストアップデート」）を未然に防ぐことができます。ユーザーには「他のユーザーが更新したため、再度読み込み直してください」といった案内を出すのが一般的です。

2. 楽観ロックの処理フローと失敗時の対応

2. 楽観ロックの処理フローと失敗時の対応

Spring Bootで楽観ロックがどのように動作するのか、その仕組みを具体的かつシンプルに紐解いていきましょう。基本的には、データの「バージョン番号」をチェックすることで、後から割り込んできた更新を防ぐ仕組みです。

プログラミングに慣れていない方のために、身近な「共有ドキュメントの編集」を例にしたサンプルプログラムを見てみましょう。

// サービス層での処理イメージ
@Service
public class DocumentService {
    
    @Transactional
    public void updateContent(Long id, String newContent) {
        // 1. 編集前のデータを取得（この時、内部でversion番号も保持される）
        Document doc = repository.findById(id).orElseThrow();
        
        // 2. 内容を書き換える
        doc.setContent(newContent);
        
        // 3. 保存実行（Springが自動でDBのversionと比較し、不一致なら例外を出す）
        repository.save(doc);
    }
}

もし、あなたが「保存ボタン」を押す数秒前に、同僚が同じドキュメントを更新していたらどうなるでしょうか？その場合、SpringはOptimisticLockingFailureExceptionという例外を発生させます。

このエラーは「システム故障」ではなく、データの整合性を守ったという「安全装置の作動」です。開発者はこの例外をキャッチし、ユーザーに「他の人が更新しました。最新の状態を確認してから、もう一度入力してください」といったメッセージを表示する親切な設計を行うことが重要です。

3. 悲観ロックとは？LockModeTypeで排他制御

3. 悲観ロックとは？LockModeTypeで排他制御

悲観ロックは、「同時に他の人が更新するかもしれない」という前提で、読み取り時にロックを取得して他のトランザクションを待たせる仕組みです。

Springでは、EntityManagerを使用して明示的にLockModeType.PESSIMISTIC_WRITEを指定することで、悲観ロックを実現できます。

@PersistenceContext
private EntityManager entityManager;

public Product getProductWithLock(Long id) {
    return entityManager.find(Product.class, id, LockModeType.PESSIMISTIC_WRITE);
}

このコードでは、商品データを読み込むと同時に書き込みロックがかかり、他のトランザクションはロックが解放されるまで待たされます。

4. 楽観ロックと悲観ロックの違いと使い分け

「4. 楽観ロックと悲観ロックの違いと使い分け」の重要ポイントを、初心者の方にも分かりやすく簡潔に解説します。

4. 楽観ロックと悲観ロックの違いと使い分け

楽観ロックと悲観ロックは、トランザクションの競合に対する考え方が異なります。下記のような基準で使い分けると良いでしょう。

• 楽観ロック：更新衝突があまり発生しないケース（例：商品詳細の編集）
• 悲観ロック：高頻度に競合が発生するケース（例：在庫管理、予約処理）

楽観ロックは非同期処理やWebアプリ向きで、悲観ロックはリアルタイム性が求められるバッチ処理などで多用されます。

5. Spring Data JPAで悲観ロックを使う方法

5. Spring Data JPAで悲観ロックを使う方法

Spring Data JPAでも、リポジトリメソッドに@Lockアノテーションを付けることで悲観ロックが使えます。

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT p FROM Product p WHERE p.id = :id")
Optional<Product> findByIdForUpdate(@Param("id") Long id);

このように指定することで、該当のデータに書き込みロックがかかり、同時アクセスの整合性が保たれます。

6. 楽観ロックで発生する例外の種類と対処

6. 楽観ロックで発生する例外の種類と対処

@Versionによる楽観ロックでは、以下のような例外が発生する可能性があります。

• OptimisticLockException（JPA標準）
• ObjectOptimisticLockingFailureException（Spring）

これらの例外は、catchしてリトライする実装を行うことでユーザーに優しい設計が可能です。

try {
    userService.updateUser(user);
} catch (ObjectOptimisticLockingFailureException e) {
    // ログを記録して再読み込みを促すなどの対応
}

7. 楽観ロックと悲観ロックの注意点とベストプラクティス

「7. 楽観ロックと悲観ロックの注意点とベストプラクティス」の重要ポイントを、初心者の方にも分かりやすく簡潔に解説します。

7. 楽観ロックと悲観ロックの注意点とベストプラクティス

ロックは強力な仕組みですが、使い方を誤るとパフォーマンスの低下やデッドロックの原因になります。

• 必要な範囲にだけロックを使う
• リトライ設計を取り入れる
• デッドロックの可能性を避けるためロック順を統一する
• 悲観ロック使用時はtimeout設定を忘れずに

特に高トラフィックなWebサービスでは、楽観ロックを基本に設計し、必要な場面だけ悲観ロックを使うのが一般的なベストプラクティスです。

まとめ

まとめ

本記事では、Springにおける楽観ロックと悲観ロックの基本概念から、@Version の具体的な使い方、LockModeType を活用した排他制御の手法、さらに例外発生時のリトライ処理や実運用での注意点までを体系的に整理してきました。楽観ロックはデータ更新の衝突が少ない環境で真価を発揮し、Webアプリケーションのように多数のユーザーが並行してデータを扱う場合でも軽量に整合性を保つことができます。一方で、悲観ロックは確実にデータの一貫性を担保したい金融システムや在庫数の更新のようなケースに向いており、トランザクション管理の正確さが求められる場面で力を発揮します。 実装面では、Spring Data JPA が提供する @Version によるバージョン管理や、EntityManager・@Lock アノテーションを通じたロックモード指定など、開発者が意識すべきポイントは多岐にわたります。特に、実運用ではロックの種類を適切に選び、不要な競合やデッドロックを避けながらアプリケーション全体のパフォーマンスと安全性を両立させる設計が欠かせません。 また、ロックの仕組みを理解すると、更新時の例外処理やユーザーへの案内方法、再試行ロジックの導入といった、より実践的な開発にも活かすことができ、日々の業務に直結する知識となるでしょう。ここではより具体的なコード例を交えながら、まとめとしてもう一度整理していきます。

■ ロックを使った整合性確保の基本コード例

下記は、楽観ロックを用いた更新処理のサンプルです。エンティティのバージョンチェックによって、競合があった場合には例外が発生し、整合性を保つ動作が自然に組み込まれています。

@Transactional
public void updateStock(Long id, int newStock) {
    Product product = productRepository.findById(id)
                                      .orElseThrow(() -> new IllegalArgumentException("not found"));

    product.setStock(newStock);

    try {
        productRepository.save(product);
    } catch (ObjectOptimisticLockingFailureException e) {
        // 再読み込みやリトライなどの設計が必要
        throw new RuntimeException("在庫が他のユーザーに更新されました。もう一度お試しください。");
    }
}

悲観ロックを使う場面では、同時に更新される可能性が高い値に対して書き込みロックを取得することで、安全に排他制御を行うことができます。デッドロックや性能劣化に注意しつつ、必要な箇所にのみ適用することが重要です。

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT p FROM Product p WHERE p.id = :id")
Optional<Product> findByIdForUpdate(@Param("id") Long id);

このように、楽観ロック・悲観ロックの両方を状況に合わせて使い分けることで、Springアプリケーションの安全性とパフォーマンスを高いレベルで両立させることができます。柔軟に適切なロック手法を選択すれば、データ更新の整合性はもちろん、ユーザー体験の向上にもつながります。

この記事を読んだ人からの質問

この記事を読んだ人からの質問

プログラミング初心者からのよくある疑問／質問を解決します

Springで楽観ロックとは何ですか？@Versionはどのような意味ですか？

楽観ロックは同時更新されない前提で処理し、更新時にバージョン番号が一致しない場合に例外を発生させて整合性を保つ仕組みです。Springでは@Versionアノテーションを使うことで自動的にバージョンチェックが行われます。

Springの悲観ロックはどんなときに使うべきですか？

悲観ロックは同時に他の人が更新する可能性が高い状況、たとえば在庫数の操作や予約システムなど、確実に排他制御が必要な場面で使用されます。