Chained Transaction Manager deprecated

1️⃣ ChainedTransactionManager는 정확히 무엇을 하는가

ChainedTransactionManager는 여러 개의 PlatformTransactionManager를 하나처럼 묶어서 트랜잭션을 제어한다.

ChainedTransactionManager(
  txManager1,  // 예: JPA1
  txManager2   // 예: JPA2
)

위와 같은 구조일 때 트랜잭션 처리 순서는 아래와 같다.

트랜잭션 시작
txManager1.begin()
txManager2.begin()

커밋 / 롤백(역순)
txManager2.commit()
txManager1.commit()

javadoc을 보면 가장 깨질 가능성이 높은 트랜잭션 매니저를 마지막에 둬야한다고 되어있다.

javadoc 참고자료

 

---

2️⃣ 이 구조의 치명적인 문제 부분 커밋

javadoc 내용을 보면 첫 번째 트랜잭션은 커밋에 성공했지만 후속 트랜잭션은 커밋에 실패한 상태가 될 수 있다고 되어있다.

javadoc 참고자료

 

트랜잭션 시작
txManager1.begin() : mysql_1
txManager2.begin() : mysql_2

커밋 / 롤백(역순)
txManager2.commit() -> 성공
txManager1.commit() -> 실패(I/O 오류, 네트워크 장애 등)

결과
mysql_2는 커밋됨
mysql_1은 롤백됨 -> 데이터 불일치 발생

---

3️⃣ Spring은 왜 이렇게 구조를 만들었는가?

javadoc 참고자료

 

• commit 전에 실패 → 전부 rollback → 비교적 안전
• commit 도중 실패 → 일부만 commit → 최악

 

ChainedTransactionManager는 "실패는 항상 커밋 전에 난다"라는 가정을 바탕으로 구현됨

---

4️⃣ Spring이 공식적으로 권장하는 대안

javadoc 참고자료

ChainedTransactionManager를 commit callback 용도로 쓰지말고, 부분 커밋된 트랜잭션으로 인한 불일치 상태를 허용하거나 복구할 수 있는 경우에만 사용하라.

 

단일 트랜잭션의 라이프사이클에 훅을 거는 용도라면 TransactionSynchronization를 대안으로 권장하고 있다.

---

5️⃣ TransactionSynchronization 란?

트랜잭션에는 생명주기가 있는데

트랜잭션 시작
 ├─ beforeCommit
 ├─ 실제 commit
 ├─ afterCommit
 └─ afterCompletion (commit or rollback)
트랜잭션 종료

훅을 건다라는 뜻은 위의 시점들 중에서 특정 순간에 코드를 끼워 넣는 것을 의미한다. 

@Transactional
public void createOrder() {

    orderRepository.save(order);

    TransactionSynchronizationManager.registerSynchronization(
        new TransactionSynchronization() {

            @Override
            public void afterCommit() {
                sendSlackMessage();
            }

            @Override
            public void afterCompletion(int status) {
                if (status == STATUS_ROLLED_BACK) {
                    cleanupTempFiles();
                }
            }
        }
    );
}

이 코드에서:

• 트랜잭션은 하나
• Slack 메시지는 DB 커밋이 성공한 후에만 실행
• DB 롤백되면 Slack 메시지 x

데이터 정합성 완벽 보장

 

 

Ref) Spring Boot 공식홈페이지