承認プロセスや複数のフォームデータ処理においてデータの書き戻しが必要な場合、イベントリスナーを利用して処理を実装できます。

1. メソッドに@EventListenerアノテーションを追加する

"#workflowEvent.processCode.startsWith('leave')" の解説:

workflowEvent: メソッドのパラメータ

processCode: workflowEventのプロパティ

startsWith: processCodeの型のメソッド（ここではString型）

@org.springframework.context.event.EventListener(condition = "#workflowEvent.processCode.startsWith('leave')")
    public void handleWorkflowEvent(WorkflowEvent workflowEvent) {
        log.info("タスクが作成されました: {}", workflowEvent.toString());<br></br>　　　　　// ここでコールバックイベントのデータ処理を実装
    }

2. イベントリスナーのトリガー

/**
     * タスク作成イベントの実行
     *
     * @param processCode プロセス定義コード
     * @param entity インスタンスデータ
     * @param taskId タスクID
     */
    public void executeWorkflowEvent(String processCode, Entity entity, Long taskId) {
        String tenantId = SecurityContext.getTenantId();
        
        WorkflowEvent workflowEvent = new WorkflowEvent();
        workflowEvent.setProcessCode(processCode);
        // イベントの発行
        ApplicationContextProvider.context().publishEvent(workflowEvent);
    }

3. 具体的なデータ処理はSpringが管理するWorkflowEventHandler内で行い、イベントトリガーメソッドを呼び出します

// データ処理が完了したらイベントを発行
workflowEventHandler.executeWorkflowEvent(definition.getProcessCode(), entity, task.getId());

実行フロー: 3.データ処理 => 2.イベントトリガー => 1.イベントリスナーメソッドのコールバック

@EventListenerと@TransactionalEventListenerの比較分析：トランザクションコミットと実行順序

Springフレームワークにおけるイベントリスナー機構は、疎結合なアーキテクチャを実現する重要な手段ですが、@EventListenerと@TransactionalEventListenerはトランザクション関連イベントの処理において明確な差異があります。以下では、トランザクションライフサイクル、実行順序、データ一貫性の観点から比較分析を行います。#### 一、基本メカニズムの比較

二、トランザクションコミットと実行順序の分析

1. トランザクションライフサイクルとイベントトリガーポイント

    A[トランザクション開始] --> B[ビジネス操作]
    B --> C{トランザクション成功?}
    C -- 成功 --> D[トランザクションコミット前]
    C -- 失敗 --> E[トランザクションロールバック]
    D --> F[トランザクションコミット]
    F --> G[トランザクションコミット後]
    E --> H[トランザクションロールバック後]
    
    % イベントトリガーポイント
    D -. @EventListener(デフォルト) .-> I[イベント処理（失敗するとトランザクションがロールバックされる可能性）]
    F -. @TransactionalEventListener(AFTER_COMMIT) .-> J[イベント処理（データは永続化済み）]
    E -. @TransactionalEventListener(AFTER_ROLLBACK) .-> K[イベント処理（データは変更なし）]

2. @EventListenerの実行順序の問題点

@Service
public class AccountService {
    
    @Transactional
    public void updateAccountStatusAndPublishEvent(Long accountId) {
        accountRepository.updateStatus(accountId, "INACTIVE");
        
        // イベント発行（この時点ではトランザクションは未コミット）
        eventPublisher.publishEvent(new AccountStatusChangedEvent(accountId));
        
        // 例外をスローしてトランザクションをロールバックする場合
        if (shouldRollback()) {
            throw new RuntimeException("トランザクションロールバックのシミュレーション");
        }
    }
}

@Service
public class AccountEventListener {
    
    @EventListener
    public void handleAccountStatusChange(AccountStatusChangedEvent event) {
        // 問題点1：トランザクションがロールバックされてもこの処理は実行される（データは永続化されていない）
        logService.recordLog("アカウントの状態が変更されました");
        
        // 問題点2：ここでデータベースをクエリすると、未コミットのデータを読み取る可能性がある
        Account account = accountRepository.findById(event.getAccountId()).get();
    }
}

• 主な問題点：
• イベント処理はトランザクションコミット前に実行される可能性があり、トランザクションがロールバックされた場合、イベント処理の結果とデータベースの状態が不一致になります。
• イベント処理にデータベースクエリが含まれている場合、未コミットの一時データを読み取るリスク（ダーティリード）があります。

3. @TransactionalEventListenerのトランザクション段階制御

@Service
public class AccountEventHandler {
    
    // トランザクションコミット後の実行（推奨シナリオ：データが永続化された後に処理）
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void handleAfterCommit(AccountStatusChangedEvent event) {
        // 安全な操作：トランザクションはコミ済みでデータが確実に存在する
        sendNotification(event.getAccountId());
    }
    
    // トランザクションコミット前の実行（注意が必要：トランザクションはロールバックされる可能性がある）
    @TransactionalEventListener(phase = TransactionPhase.BEFORE_COMMIT)
    public void handleBeforeCommit(AccountStatusChangedEvent event) {
        // トランザクション内で連携する操作に適していますが、ロールバックのリスクを負います
    }
    
    // トランザクションロールバック後の実行（補正ロジックの処理）
    @TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)
    public void handleAfterRollback(AccountStatusChangedEvent event) {
        // 一時リソースのクリーンアップまたはロールバックログの記録
    }
}

• 実行順序の利点：
• phaseパラメータを使用して、イベントがトランザクションのどの段階で実行されるかを正確に制御し、データの不一致を回避します。
• AFTER_COMMIT段階では、イベント処理時にデータが永続化されていることが保証され、後続の操作が安全です。
• AFTER_ROLLBACKはトランザクション失敗後の補正ロジック（キャッシュのクリーンアップなど）に使用できます。

三、非同期シナリオにおける特殊な考慮事項

@Asyncと組み合わせて非同期イベント処理を実装する場合、両者の動作の差異はさらに明確になります： ``` @Service public class AsyncAccountListener {

// @EventListener + @Asyncのリスクシナリオ
@Async
@EventListener
public void asyncHandleAccountDeletion(AccountDeletedEvent event) {
    // 非同期スレッドで実行され、元のトランザクションはまだコミットされていない可能性がある
    // この時点でデータベースをクエリすると、削除されていないデータを読み取る可能性がある（トランザクション未コミットのため）
    Account account = accountRepository.findById(event.getAccountId()).orElse(null);
    // accountがnullでない場合、ロジックエラーが発生する可能性がある
}

// @TransactionalEventListener + @Asyncの正しい実装方法
@Async
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void safeAsyncHandleAccountDeletion(AccountDeletedEvent event) {
    // トランザクションはコミット済みでデータは削除済みなので、クエリ結果は正しい
    Account account = accountRepository.findById(event.getAccountId()).orElse(null);
    // accountは必ずnullになる
}

}

- 主な差異：
- `@EventListener + @Async`は、トランザクションが未コミットであるため、非同期スレッドで古いデータを読み取る可能性があります。
- `@TransactionalEventListener + @Async`は、トランザクションコミット後に非同期処理を実行するため、データの可視性が保証されます。

#### 四、適用シナリオとベストプラクティス

| シナリオタイプ | 推奨アノテーション | 理由 |
|---|---|---|
| 通常のビジネスイベント（トランザクション依存なし） | `@EventListener` | トランザクション状態を認識する必要がなく、実行効率が高い |
| トランザクション関連イベント（データ永続化後の通知など） | `@TransactionalEventListener` | イベントをトランザクションコミット後に実行し、データの不一致を回避 |
| サービス間データ同期（最終一貫性） | `@TransactionalEventListener` | `AFTER\_COMMIT`段階と組み合わせて、ローカルトランザクション成功後にリモート操作をトリガー |
| トランザクションロールバック時の補正ロジック | `@TransactionalEventListener` | `AFTER\_ROLLBACK`段階でトランザクション失敗後のクリーンアップ処理を実装 |

#### 五、まとめ：実行順序とトランザクションコミットの関係

1. @EventListener：
- イベント発行時に即時実行され、トランザクションコミット前に実行される可能性があります。
- トランザクションがロールバックされた場合、イベント処理の結果とデータベースの状態が不一致になります。
- トランザクション結果に依存しない軽量イベントに適しています。
2. @TransactionalEventListener：
- トランザクションコミット後/前/ロールバック時に実行を正確に制御できます。
- `AFTER_COMMIT`は最も一般的に使用される段階で、データの永続化後にイベントを処理します。
- データ一貫性を保証する必要があるシナリオ（例：支払い成功後の通知送信）に適しています。

適切なイベントリスナー方式を選択することで、システムの疎結合設計においてトランザクションの一貫性を同時に保証し、時序の問題によるデータ不一致のリスクを回避できます。