Springの宣言型トランザクションについて


「宣言型トランザクション」は、Springフレームワークにおいて最も中核的な機能の一つであり、日常の開発において最も頻繁に使用される機能の一つでもあります。

簡単に言えば、宣言型トランザクションとは、「具体的な方法ではなく、何を行うかをフレームワークに伝える」ものです。これにより、トランザクション管理のコードがビジネスロジックから完全に分離され、開発者はアノテーション（例：@Transactional）やXML設定で宣言するだけで、フレームワークが自動的にトランザクションの開始、コミット、ロールバックを処理します。

面接や実際のアプリケーション開発において、この概念を徹底的に説明できるよう、比較、内部原理、機能しないシナリオ（頻出の試験ポイント）という3つの観点から深く解説していきます。

一、 なぜ宣言型トランザクションを使うのか？（プログラム型トランザクションとの比較）

Springが登場する前、あるいはSpringでプログラム型トランザクションを使用する場合、コードは次のようになります：

// プログラム型トランザクション：トランザクションコードと業務コードが強く結合している
public void createOrder() {
    TransactionStatus status = transactionManager.getTransaction(configuration);
    try {
        // 1. 在庫の減算
        inventoryService.deduct();
        // 2. 注文の作成
        orderMapper.insert();
        transactionManager.commit(status); // 手動でのコミット
    } catch (Exception e) {
        transactionManager.rollback(status); // 手動でのロールバック
        throw e;
    }
}

課題 ：画面いっぱいに try-catch や commit/rollback が並び、業務ロジックがトランザクション管理コードに埋もれてしまい、コードの侵入性が極めて高く、ミスも起こりやすい（例えば、特定の例外の catch を忘れてロールバックが行われないなど）。

宣言型トランザクションの登場により、この問題は解決された：

// 宣言型トランザクション：業務コードが極めて純粋
@Transactional(rollbackFor = Exception.class)
public void createOrder() {
    inventoryService.deduct();
    orderMapper.insert();
    // フレームワークが自動的にコミットとロールバックを処理
}

中核となる考え方 ：AOP（アスペクト指向プログラミング） に基づいて、関心事の分離を実現する。

二、 基礎原理：Springはどのようにトランザクションを「自動」で管理しているのか？

これは面接で最も深く掘り下げられるポイントだ。宣言型トランザクションの本質は AOP + 動的プロキシ + トランザクションインターセプターである。

メソッドに @Transactional を付与すると、Springは起動時に以下の処理を行います：

  1. アノテーションの解析 ：Springコンテナの起動時、Beanに付与された @Transactional アノテーションを解析し、トランザクション属性（分離レベル、伝播挙動、ロールバックルールなど）を抽出します。
  2. プロキシオブジェクトの作成 ：SpringはこのBeanにトランザクション管理が必要であると検知すると、AOPを利用して、そのBean用のプロキシオブジェクトを生成します（対象クラスがインターフェースを実装している場合はデフォルトでJDKの動的プロキシを使用し、そうでない場合はCGLIBプロキシを使用します）。コンテナから取得するのは、実際には元のオブジェクトではなく、プロキシオブジェクトです。
  3. インターセプターによる引き継ぎ（コア） ：プロキシオブジェクトの内部には、コアとなるインターセプター ------ TransactionInterceptorがバインドされています。
  4. 実行フロー ：
    • プロキシオブジェクトのメソッドを呼び出すと、リクエストはまず TransactionInterceptor に到達します。
    • インターセプターは PlatformTransactionManager（トランザクションマネージャー）を取得します。
    • トランザクションを開始 ： getTransaction() を呼び出し、データベース接続を取得してトランザクションを開始します。
    • ビジネスロジックの実行 ：ターゲットオブジェクトの実際のメソッド（proceed()）を呼び出します。
    • 例外処理 ：メソッドが例外をスローした場合、インターセプターが例外をキャッチし、ロールバックルールに合致するかどうかを判断します。合致する場合は rollback() を呼び出し、そうでない場合は commit() を呼び出します。

原理を一言でまとめると ：実際にはプロキシオブジェクトのメソッドを呼び出しており、プロキシオブジェクトはトランザクションインターセプターを通じて、ビジネスロジックの実行前後に自動的に Connection.commit() または Connection.rollback() を呼び出します。

3. 実戦と面接で頻出するポイント：@Transactional が機能しなくなる 6 つのシナリオ

実際の開発や面接において、「宣言型トランザクションの失敗」は必ず出題される問題です。基盤が AOP プロキシに依存しているため、プロキシオブジェクトを迂回するいかなる行為も、トランザクションの失敗につながります。

1. 同一クラス内のメソッド呼び出し（自己呼び出しの問題）------ 最もよくある落とし穴
@Service
public class OrderService {
    
    public void methodA() {
        this.methodB(); // 同一クラスのメソッドを直接呼び出し、プロキシをバイパス！
    }
    
@Transactional
    public void methodB() {
        // ここでの @Transactional は有効になりません！
    }
}
  • 原因 ：methodA が methodB を呼び出す際、使用されているのは this （ターゲットオブジェクト自体）が使用されており、Springによって注入されたプロキシオブジェクトではありません。プロキシを経由しないため、TransactionInterceptorは実行されません。
  • 解決策 ：
    1. methodBを別のServiceに分離する（推奨、単一責任の原則に準拠）。
    2. 自身を注入する：@Lazy @Autowired private OrderService self; その後、self.methodB()。
    3. AopContext.currentProxy() を使用して、現在のプロキシオブジェクトを取得する。
2. メソッドが public ではない場合
  • 原因 ：Spring AOP はデフォルトで public メソッドのみをインターセプトします。protected、private、またはパッケージ内でのみ可視なメソッドにアノテーションを付与すると、アノテーションは直接無効になります（Spring 4.0 以降ではエラーが直接発生するか、無視されます） 。
  • 解決策 ：素直に public 修飾子を追加してください。
3. 例外が catch によって吸収されてしまった
@Transactional
public void createOrder() {
    try {
        orderMapper.insert();
        
int i = 1 / 0; // 例外をスロー
    } catch (Exception e) {
        log.error(「エラーが発生しました」, e); 
        // 例外がキャッチされ、トランザクションインターセプターに投げられませんでした！
    }
}
  • 原因 ： トランザクションインターセプターは例外を検知できず、メソッドが正常に実行完了したと判断したため、commit()が実行されました。
  • 解決策 ：catchブロック内でログ処理を終えた後、必ずthrow eまたはthrow new RuntimeException(e)として例外をスローする必要があります。
4. スローされた例外の型がロールバックルールに適合しない
  • 原因 ：Spring @Transactional はデフォルトで、RuntimeException および Error に対してのみロールバックを行います 。コードでチェック例外（例：IOException、SQLException）がスローされた場合、トランザクションはロールバックされず、コミットされてしまいます！
  • 解決策 ：常に rollbackFor 属性を追加してください：@Transactional(rollbackFor = Exception.class)。これはエンタープライズ開発における鉄則です。
5. データベースエンジン自体がトランザクションをサポートしていない
  • 原因 ：例えば、MySQLのテーブルエンジンが MyISAM（トランザクションをサポートしていない）の場合、いくら @Transactional を追加しても意味がありません。
  • 解決策 ：データベースのテーブルエンジンが InnoDB であることを確認してください。
6. 伝播挙動（Propagation）の設定ミス
  • 原因 ：@Transactional(propagation = Propagation.NOT_SUPPORTED)と設定した場合、「非トランザクションモードで実行し、現在トランザクションが存在する場合はサスペンドする」という意味になります。これもトランザクションが有効にならない原因となります。

4. 応用補足：トランザクションの伝播挙動（Propagation）

複数のトランザクションメソッドが相互に呼び合う場合、Springはどのようにトランザクションの境界を決定するのでしょうか？これが伝播挙動です。最もよく使われるものは3つあります：

  1. REQUIRED（デフォルト）：現在トランザクションが存在する場合、それに参加します。存在しない場合は、新しいトランザクションを作成します。（95%のシナリオでこれを使用します）。
  2. REQUIRES_NEW ：現在トランザクションの有無にかかわらず、現在のトランザクションをサスペンドし、独立した新しいトランザクションを作成します。内側のトランザクションのロールバックは、外側のトランザクションには影響を与えません。（主な用途：操作ログの記録。メインの業務処理がロールバックされても、ログは保存される必要があります）。
  3. NESTED ：現在トランザクションが存在する場合、ネストされたトランザクション内で実行されます（基盤となるデータベースのSavepointセーブポイント機構に依存しています）。内側のトランザクションがロールバックされると、外側のトランザクションもロールバックされますが、外側のトランザクションがロールバックされても、内側のトランザクションが必ずしもロールバックされるとは限りません（具体的な実装に依存します）。

五、 まとめ

宣言型トランザクションは、Springが提供する極めて洗練されたソリューションであり、AOP動的プロキシを利用して、トランザクション管理をビジネスロジックから分離しています。

しかし、その利便性を享受する一方で、その限界と落とし穴を常に念頭に置いておく必要があります：

  1. 「プロキシオブジェクト」という概念をしっかりと理解し、自己呼び出しによる失敗を回避してください。
  2. 常に @Transactional(rollbackFor = Exception.class)を使用してください。
  3. 例外が正しくスローされることを確認し、catchによって吸収されないようにしてください。
  4. 複雑な複数データソースやネストされた呼び出しのシナリオでは、伝播挙動を適切に設定してください。