스프링의 트랜잭션 전파(REQUIRED, REQUIRES_NEW)

REQUIRED 옵션

[참고] 트랜잭션 전파 옵션
스프링은 다양한 트랜잭션 전파 옵션을 제공한다. 전파 옵션에 별도의 설정을 하지 않으면 REQUIRED가 기본으로 사용된다. 참고로 실무에서는 대부분 REQUIRED 옵션을 사용한다. 그리고 아주 가끔 REQUIRES_NEW을 사용하고, 나머지는 거의 사용하지 않는다.
* REQUIRED: 가장 많이 사용하는 기본 설정이다. 기존 트랜잭션이 없으면 생성하고, 있으면 참여한다.
* REQUIRES_NEW: 항상 새로운 트랜잭션을 생성한다. 기존 트랜잭션이 없으면 생성하고, 있어도 새로운 트랜잭션을 생성한다.

 

트랜잭션이 수행중이고 아직 끝나지 않았는데 또 다른 트랜잭션이 수행되면 어떻게 될까? 이때 처음 시작된 트랜잭션을 상대적으로 밖에 있기 때문에 외부 트랜잭션이라고 하고, 이후에 시작된 트랜잭션을 외부 트랜잭션 수행 도중에 호출되기 때문에 내부에 있는 것처럼 보여서 내부 트랜잭션이라고 한다. (스프링은 트랜잭션 전파 옵션에 따라 다르게 동작하는데, REQUIRED를 기준으로 설명하겠다.)

그리고 논리 트랜잭션과 물리 트랜잭션이란 개념으로 나눈다.

• 물리 트랜잭션은 실제 데이터베이스에 적용되는 트랜잭션이다. 즉, 실제 커넥션을 통해 트랜잭션을 시작, 커밋, 롤백하는 단위이다.
• 논리 트랜잭션은 트랜잭션 매니저를 통해서 트랜잭션을 사용하는 단위로, 실제 데이터베이스에 반영되지 않는다.
• 모든 논리 트랜잭션이 커밋되어야 물리 트랜잭션이 커밋된다. 논리 트랜잭션 중 하나라도 롤백되면 물리 트랜잭션은 롤백된다.

내부 커밋, 외부 커밋

@SpringBootTest
@Slf4j
public class TxTest {

    @Autowired
    PlatformTransactionManager txManager; // 스프링 부트는 라이브러리를 보고, 적절한 트랜잭션 매니저를 transactionManager라는 이름의 스프링 빈에 등록한다.

    @Test
    void inner_commit() {
        log.info("외부 트랜잭션 시작");
        TransactionStatus outerTx = txManager.getTransaction(new DefaultTransactionAttribute());
        log.info("outerTx.isNewTransaction() = {}", outerTx.isNewTransaction());

        log.info("내부 트랜잭션 시작");
        TransactionStatus innerTx = txManager.getTransaction(new DefaultTransactionAttribute());
        log.info("innerTx.isNewTransaction() = {}", innerTx.isNewTransaction());

        log.info("내부 트랜잭션 커밋");
        txManager.commit(innerTx);

        log.info("외부 트랜잭션 커밋");
        txManager.commit(outerTx);
    }
}

• 외부 트랜잭션은 처음 수행한 트랜잭션이다. 따라서 이 경우 isNewTransaction()의 결과는 true이다. 
• 내부 트랜잭션을 시작하는 시점에는 이미 외부 트랜잭션이 진행중인 상태이다. 따라서 내부 트랜잭션은 외부 트랜잭션에 참여한다. 내부 트랜잭션이 외부 트랜잭션에 참여한다는 것은 외부 트랜잭션과 내부 트랜잭션이 하나의 물리 트랜잭션으로 묶이는 것이다. 따라서 이 경우 내부 트랜잭션은 신규 트랜잭션이 아니므로 isNewTransaction()의 결과는 false이다.
• 외부 트랜잭션을 시작할 때는 Creating new transaction이라는 로그가 찍혔고, 외부 트랜잭션을 커밋할 때는 Initiating transaction commit이라는 로그가 찍혔다. 
• 그러나 내부 트랜잭션을 시작할 때는 시작한다는 로그가 아닌 Participating in existing transaction이라는 로그가 찍혔고, 내부 트랜잭션을 커밋할 때는 어떠한 로그도 찍히지 않았다. 
• 즉 외부 트랜잭션만 실제 데이터베이스에 적용되는 물리 트랜잭션을 시작하고 커밋한다.
• 만약 내부 트랜잭션이 실제 물리 트랜잭션을 커밋하면 트랜잭션 자체가 끝나버리기 때문에 트랜잭션을 처음 시작한 외부 트랜잭션까지 이어갈 수 없다. 따라서 내부 트랜잭션은 DB 커넥션을 통한 물리 트랜잭션을 커밋하면 안된다. 
• 즉 스프링은 이렇게 여러 트랜잭션이 함께 사용되는 경우, 처음 트랜잭션을 시작한 외부 트랜잭션이 실제 물리 트랜잭션을 관리하도록 한다.

요청 흐름

 

1. [외부 트랜잭션] txManager.getTransaction()을 통해 외부 트랜잭션을 시작한다.
2. 트랜잭션 매니저는 데이터소스를 통해 커넥션을 생성한다.
3. 생성한 커넥션을 수동 커밋 모드로 설정한다. (물리 트랜잭션 시작)
4. 트랜잭션이 시작된 커넥션은 트랜잭션 동기화 매니저에 보관된다.
5. 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus에 담아서 반환하는데, 여기에 신규 트랜잭션의 여부(isNewTransaction())가 담겨있다. (isNewTransaction() = true)
6. 로직 1이 사용되고 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 트랜잭션이 적용된 커넥션을 획득해서 사용한다.
7. [내부 트랜잭션] txManager.getTransaction()을 통해 내부 트랜잭션을 시작한다.
8. 트랜잭션 매니저는 트랜잭션 동기화 매니저를 통해서 기존 트랜잭션이 존재하는지 확인한다. 
9. 기존 트랜잭션이 존재하므로, 기존 트랜잭션에 참여한다. 이미 기존 트랜잭션인 외부 트랜잭션에서 트랜잭션이 적용된 커넥션을 생성하고 트랜잭션 동기화 매니저에 담아두었다. 따라서 내부 트랜잭션은 아무것도 하지 않아도 되며, 이후 커넥션이 필요할 때 외부 트랜잭션이 생성해둔 트랜잭션 동기화 매니저에 담긴 커넥션을 사용하면 된다.
10. 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus에 담아서 반환하는데, 여기에 신규 트랜잭션의 여부(isNewTransaction())가 담겨있다. (isNewTransaction() = false)
11.  로직 2가 사용되고 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 트랜잭션이 적용된 커넥션을 획득해서 사용한다.

응답 흐름

1. [내부 트랜잭션] 로직 2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋한다. 
2. 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 이 경우 신규 트랜잭션이 아니므로 실제 커밋을 호출하지 않는다. (만약 내부 트랜잭션이 실제 커넥션의 커밋이나 롤백을 호출하면, 실제 물리 트랜잭션이 끝나버린다. 아직 트랜잭션이 끝나지 않았기 때문에 트랜잭션을 종료하면 안된다.)
3. [외부 트랜잭션] 로직 1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋한다.
4. 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 이 경우 신규 트랜잭션이므로 실제 커밋을 호출한다.
5. 트랜잭션 매니저에 커밋하는 것이 논리적인 커밋이라면, 실제 커넥션에 커밋하는 것을 물리적인 커밋이라고 할 수 있다. 실제 데이터베이스에 커밋이 반영되고, 실제 물리 트랜잭션도 종료된다.

내부 롤백, 외부 커밋 - UnexpectedRollbackException 발생

그렇다면 내부 트랜잭션이 롤백하는데 외부 트랜잭션이 커밋하는 경우에는 어떻게 될까? 앞서 살펴본 바로는, 내부 트랜잭션의 커밋/롤백은 실제 물리적인 트랜잭션에 영향을 주지 않으므로 물리 트랜잭션이 커밋될 거 같다. 그러나 결과는 UnexpectedRollbackException이 발생한다.

@SpringBootTest
@Slf4j
public class TxTest {

    @Autowired
    PlatformTransactionManager txManager; // 스프링 부트는 라이브러리를 보고, 적절한 트랜잭션 매니저를 transactionManager라는 이름의 스프링 빈에 등록한다.

    @Test
    void inner_rollback() {
        log.info("외부 트랜잭션 시작");
        TransactionStatus outerTx = txManager.getTransaction(new DefaultTransactionAttribute());
        log.info("outerTx.isNewTransaction() = {}", outerTx.isNewTransaction());

        log.info("내부 트랜잭션 시작");
        TransactionStatus innerTx = txManager.getTransaction(new DefaultTransactionAttribute());
        log.info("innerTx.isNewTransaction() = {}", innerTx.isNewTransaction());

        log.info("내부 트랜잭션 롤백");
        txManager.rollback(innerTx);

        log.info("외부 트랜잭션 커밋");
        Assertions.assertThatThrownBy(() -> txManager.commit(outerTx))
                .isInstanceOf(UnexpectedRollbackException.class); // UnexpectedRollbackException 예외 발생
    }
}

• 내부 트랜잭션을 롤백하면 기존 트랜잭션을 롤백 전용으로 표시한다(Participating transaction failed - marking existing transaction as rollback-only).
• 그리고 외부 트랜잭션을 커밋하면 물리 트랜잭션이 롤백 전용으로 표시되어 있기 때문에 물리 트랜잭션을 롤백한다.

응답 흐름

1. [내부 트랜잭션] 로직 2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백한다.
2. 트랜잭션 매니저는 롤백 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 이 경우 신규 트랜잭션이 아니기 때문에 실제 롤백을 호출하지 않는다.
3. 내부 트랜잭션은 물리 트랜잭션을 롤백하지 않는 대신에 트랜잭션 동기화 매니저에 rollbackOnly=true라는 표시를 해둔다.
4. [외부 트랜잭션] 로직 1이 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋한다.
5. 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 이 경우 신규 트랜잭션이므로 DB 커넥션에 커밋을 호출해야 한다. 이때 먼저 트랜잭션 동기화 매니저에 롤백 전용 표시가 있는지 확인한다. 롤백 전용 표시가 있으면 물리 트랜잭션을 커밋하지 않고 롤백한다.
6. 실제 데이터베이스에 롤백이 반영되고, 물리 트랜잭션도 끝난다.
7. 트랜잭션 매니저에 커밋을 호출한 개발자 입장에서는 분명 커밋을 기대했는데 롤백 전용 표시로 인해 실제로는 롤백이 되어버렸다. 시스템 입장에서는 커밋을 호출했지만 롤백이 되었다는 것은 알려야 하는 문제이다. 예를 들어서 고객은 주문이 성공했다고 생각했는데, 실제로는 롤백이 되어서 주문이 생성되지 않은 것이다. 스프링은 이 경우 UnexpectedRollbackException 런타임 예외를 던진다. 그래서 커밋을 시도했지만, 기대하지 않은 롤백이 발생했다는 것을 명확하게 알려준다.

REQUIRES_NEW 옵션 - UnexpectedRollbackException 해결

앞서 살펴본 것과 같이 내부 트랜잭션이 외부 트랜잭션에 참여할 때, 내부 트랜잭션에서 롤백을 하고 외부 트랜잭션에서 커밋을 하면, 의도치 않은 롤백이 발생한다. 그리고 스프링은 이를 알리기 위해 UnexpectedRollbackException 예외를 발생시킨다.

 

따라서 이런 경우를 방지하려면 외부 트랜잭션과 내부 트랜잭션을 별도로 분리해서 각각의 물리 트랜잭션을 사용하면 된다. 이렇게 외부 트랜잭션과 내부 트랜잭션을 분리하려면, 내부 트랜잭션을 시작할 때 REQUIRES_NEW 옵션을 사용하면 된다. 그러면 내부 트랜잭션은 별도의 물리 트랜잭션을 가진다. 즉 별도의 DB 커넥션을 사용한다. 따라서 각 트랜잭션은 커밋/롤백이 각 커넥션을 통해 개별적으로 이뤄지며 서로에게 영향을 주지 않는다.

@SpringBootTest
@Slf4j
public class TxTest {

    @Autowired
    PlatformTransactionManager txManager; // 스프링 부트는 라이브러리를 보고, 적절한 트랜잭션 매니저를 transactionManager라는 이름의 스프링 빈에 등록한다.

    @Test
    void inner_rollback_requires_new() {
        log.info("외부 트랜잭션 시작");
        TransactionStatus outerTx = txManager.getTransaction(new DefaultTransactionAttribute());
        log.info("outerTx.isNewTransaction() = {}", outerTx.isNewTransaction());

        log.info("내부 트랜잭션 시작");
        DefaultTransactionAttribute definition = new DefaultTransactionAttribute();
        definition.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW); // REQUIRES_NEW 설정
        TransactionStatus innerTx = txManager.getTransaction(definition);
        log.info("innerTx.isNewTransaction() = {}", innerTx.isNewTransaction());

        log.info("내부 트랜잭션 롤백");
        txManager.rollback(innerTx);

        log.info("외부 트랜잭션 커밋");
        txManager.commit(outerTx);
    }
}

요청 흐름

1. [외부 트랜잭션] txManager.getTransaction()를 호출해서 외부 트랜잭션을 시작한다.
2. 트랜잭션 매니저는 데이터소스를 통해 커넥션(con1)을 생성한다.
3. 생성한 커넥션을 수동 커밋 모드로 설정한다. (물리 트랜잭션 시작)
4. 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관한다.
5. 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus에 담아서 반환하는데, 여기에 신규 트랜잭션의 여부(isNewTransaction())가 담겨있다. (isNewTransaction() = true)
6. 로직 1이 사용되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 트랜잭션이 적용된 커넥션을 획득해서 사용한다.
7. [내부 트랜잭션] REQUIRES_NEW 옵션과 함께 txManager.getTransaction()를 호출해서 내부 트랜잭션을 시작한다. 트랜잭션 매니저는 REQUIRES_NEW 옵션을 확인하고 기존 트랜잭션에 참여하는 것이 아니라 새로운 트랜잭션을 시작한다.
8. 따라서 트랜잭션 매니저는 데이터소스를 통해 커넥션(con2)을 생성한다.
9. 생성한 커넥션을 수동 커밋 모드로 설정한다. (물리 트랜잭션 시작)
10. 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관한다. 이때 con1은 잠시 보류되고 내부 트랜잭션이 끝날 때까지 con2가 사용된다. 
11. 트랜잭션 매니저는 신규 트랜잭션의 생성한 결과를 반환한다. (isNewTransaction() = true)
12. 로직 2가 사용되고 커넥션이 필요한 경우 트랜잭션 동기화 매니저에 있는 con2 커넥션이 사용된다.

응답 흐름

1. [내부 트랜잭션] 로직 2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백한다. 
2. 트랜잭션 매니저는 롤백 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 현재 내부 트랜잭션은 신규 트랜잭션이다. 따라서 실제 롤백을 호출한다.
3. 트랜잭션 매니저가 con2 커넥션에 롤백을 호출한다. 따라서 실제 물리 트랜잭션이 롤백된다. 해당 트랜잭션은 종료되고 con2는 종료되거나 커넥션 풀에 반납된다. 이후에는 con1 커넥션이 사용된다.
4. [외부 트랜잭션] 로직 1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋한다.
5. 현재 외부 트랜잭션은 신규 트랜잭션이다. 따라서 con2 커넥션에 커밋을 호출한다.
6. 그런데 이때 rollbackOnly 설정을 체크한다. rollbackOnly 설정이 없으므로 정상적으로 커밋한다.
7. 해당 트랜잭션은 종료되고 con1은 종료되거나 커넥션 풀에 반납된다. 

정리

• REQUIRED 옵션
  • 트랜잭션 매니저가 데이터소스를 통해 커넥션을 생성하고 트랜잭션 동기화 매니저에 보관하는 시점은 외부 트랜잭션이 시작되는 시점이다. 내부 트랜잭션이 트랜잭션을 시작할 때는 외부 트랜잭션에 참여한다. 그리고 내부 트랜잭션은 외부 트랜잭션이 생성해둔 커넥션을 사용한다. (커넥션 1개를 함께 사용한다.)
  • 트랜잭션 매니저가 항상 실제 커넥션에 물리적인 커밋/롤백을 발생시키는 것이 아니다. 외부 트랜잭션의 커밋/롤백의 경우에만 커넥션에 커밋/롤백을 발생시켜 물리적인 트랜잭션을 종료한다. 내부 트랜잭션이 커밋/롤백하는 경우에는 실제 커넥션에 반영되지 않는다.
  • 내부 트랜잭션이 롤백을 호출하면 트랜잭션 매니저는 실제 커넥션에 롤백을 호출하지 않고, 롤백 전용 마크(rollbackOnly=true)를 표시한다.
  • 외부 트랜잭션이 커밋을 호출하면 트랜잭션 매니저는 롤백 전용 마크를 확인한다. 표시되어 있지 않으면 정상적으로 커밋하고, 표시되어 있으면(내부 트랜잭션: 롤백, 외부 트랜잭션: 커밋) 롤백한다. 그리고 이때 스프링은 UnexpectedRollbackException 예외를 던진다. 즉 논리 트랜잭션이 하나라도 롤백되면 물리 트랜잭션은 롤백된다.
• REQUIRES_NEW 옵션
  • 트랜잭션 매니저는 트랜잭션을 시작할 때 옵션을 확인한다. REQUIRES_NEW 옵션이면 기존 트랜잭션에 참여하는 것이 아니라 새로운 트랜잭션을 시작하고, 이때 새로운 커넥션을 생성한다.
  • 따라서 REQUIRES_NEW 옵션을 사용하면 데이터베이스 커넥션이 동시에 2개 사용된다.

 

---

Reference

• 인프런, 스프링 DB 1편 - 데이터 접근 핵심 원리,김영한