[스프링 DB 2편] #10. 스프링 트랜잭션 전파1 - 기본(2)

[newh08]

스프링 트랜잭션 전파5 - 외부 롤백

내부 트랜잭션은 커밋인데 외부 트랜잭션이 롤백되는 경우, 조금 쉬운 사례.
나중에 바깥은 커밋인데 안이 롤백인 경우가 어렵고 다음 강의에서 설명할 예정.

트랜잭션 전파상황에서
논리 트랜잭션이 하나라도 롤백되면 전체 물리 트랜잭션은 롤백된다.
따라서 이 경우에 내부 트랜잭션이 커밋했어도, 내부 트랜잭션 안에서 저장한 데이터 모두 함께 롤백되어야함.

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

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

        log.info("외부 트랜잭션 롤백");
        txManager.rollback(outer);
    }

실행 로그

1. 외부 트랜잭션 시작.
2. 커넥션 가져오기
3. 커넥션 메뉴얼 커밋으로 변경
4. 내부 트랜잭션 시작
5. 기존 트랜잭션 참여하고 아무것도 하지 않음.
6. 내부 트랜잭션 커밋해도 아무것도 하지 않음.
7. 외부 트랜잭션 롤백 시작
8. 롤백 하고
9. 커낵션 릴리즈

응답 흐름

요청 흐름은 앞서 본것과 같으므로, 응답 흐름에 집중해보자.

내부 트랜잭션

1. 로직 2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋
2. 내부 트랜잭션은 신규 트랜잭션이 아니기 때문에 실제 커밋 호출하지 않음. 그래서 물리 트랜잭션은 외부 트랜잭션이 종료될 때 까지 이어짐

외부 트랜잭션
3. 로직 1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션 롤백
4. 트랜잭션 매니저는 롤백 시점에 신규 트랜잭션 여부에 따라 다르게 동작함. 지금은 신규 트랜잭션이므로 DB 커낵션에 실제 롤백을 호출함.
5. 실제 커낵션에 롤백을 호출하는 물리 롤백임. (반면 트랜잭션 매니저에 롤백하는건 논리적 롤백) 실제 데이터베이스에 롤백이 반영되고 물리 트랜잭션이 끝난다.

결국 이전에 배운 커밋상황에서 외부 트랜잭션의 커밋이 롤백으로만 바뀐것임.

다음에 알아볼 내부 트랜잭션 롤백이 조금 복잡하다.

스프링 트랜잭션 전파6 - 내부 롤백

이번엔 내부 트랜잭션은 롤백, 외부 트랜잭션이 커밋되는 상황.

이 상황은 겉으론 단순하지만 실제론 단순하지 않음,
내부 트랜잭션이 롤백했지만, 이는 물리 트랜잭션에 영향을 주지 않음
그런데 외부 트랜잭션이 커밋해버리면? 외부 트랜잭션이 물리 트랜잭션에 영향을 주니까 왠지 커밋될 것 같은데, 대 원칙에 의해 전체 롤백을 해야한다.
스프링은 이 문제를 어떻게 해결할까?

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

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

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

돌려보면 예외가 터지는데, 일단 로그 먼저 확인해보자.

• 외부 트랜잭션 시작 후, 커넥션 가져온 후 , 내부 트랜잭션 시작.
• 내부 트랜잭션 롤백 시작
• 참여한 트랜잭션이 실패했다는 로그가 찍힘. 그래서 marking existing transaction 을 rollback-only 로 한다는 로그.
• 트랜잭션에 rollback-only 라고 표시함.
• 외부 트랜잭션 커밋.
• 외부 트랜잭션이 커밋이지만, 어딘가에서 롤백 표시를 했으므로 롤백한다는 로그
• 실제로 롤백함

내부 트랜잭션 롤백

• Participating transaction failed - marking existing transaction as rollback-only
• 내부 트랜잭션을 롤백하면 실제 물리 트랜잭션은 롤백하지 않는다. 대신에 기존 트랜잭션을 롤백 전용으로 표시한다.

외부 트랜잭션 커밋

• 외부 트랜잭션을 커밋한다.
• Global transaction is marked as rollback-only
• 커밋을 호출했지만, 전체 트랜잭션이 롤백 전용으로 표시되어 있다. 따라서 물리 트랜잭션을 롤백한다.

내부 트랜잭션

1. 로직2에 문제가 생겨 트랜잭션 매니저 통해 롤백 호출
2. 트랜잭션 매니저는 신규 트랜잭션 여부에 따라 다르게 동작하는데, 지금은 신규 트랜잭션이 아니므로 실제 롤백을 호출하지 않는다. (여기서 종료해버리면 다음 로직을 할 수 없음) 물리 트랜잭션은 외부 트랜잭션을 종료할 때 까지 이어져야한다.
3. 내부 트랜잭션은 물리 트랜잭션을 롤백하지 않는 대신 트랜잭션 동기화 매니저에 rollbackOnly=true 라는 표시를 해둔다.

외부 트랜잭션
4. 로직1이 끝나고 트랜잭션 매니저를 통해 커밋 호출
5. 이번엔 신규 트랜잭션이므로 DB 커넥션에 커밋 호출해야함. 근데 그전에 먼저 rollbackOnly=true 가 잇는지 확인함. 만약 있으면 커밋이 아니라 롤백을 한다.
6. 실제 데이터베이스에 롤백을 반영하고 물리 트랜잭션도 끝난다.
7. 트랜잭션 매니저에 커밋을 호출한 개발자 입장에서는 분명 커밋을 기대했는데 롤백 전용 표시로 인해 실제로는 롤백이 되어버렸다. (아무런 노티가 없으면 개발자는 커밋이라 생각하는데 실제 디비엔 반영 안되는 상황 발생)

• 이것은 조용히 넘어갈 수 있는 문제가 아니다. 시스템 입장에서는 커밋을 호출했지만 롤백이 되었다는 것은 분명하게 알려주어야 한다.
  - 예를 들어서 고객은 주문이 성공했다고 생각했는데, 실제로는 롤백이 되어서 주문이 생성되지 않은 것이다.
  - 스프링은 이 경우 UnexpectedRollbackException 런타임 예외를 던진다. 그래서 커밋을 시도했지만, 기대하지 않은 롤백이 발생했다는 것을 명확하게 알려준다.

        Assertions.assertThatThrownBy(() -> txManager.commit(outer))
                .isInstanceOf(UnexpectedRollbackException.class);

기존 커밋 코드를 위 처럼 바꾸면 깔끔하게 테스트 가능.

정리**

• 논리 트랜잭션이 하나라도 롤백되면 물리 트랜잭션은 롤백된다.
• 내부 논리 트랜잭션이 롤백되면 롤백 전용 마크를 표시한다.
• 외부 트랜잭션을 커밋할 때 롤백 전용 마크를 확인한다. 롤백 전용 마크가 표시되어 있으면 물리 트랜잭션을 롤백 하고, UnexpectedRollbackException 예외를 던진다.

** 대원칙**
- 모든 논리 트랜잭션이 커밋되면 물리 트랜잭션이 커밋된다
- 하나의 논리 트랜잭션이 롤백되면 물리 트랜잭션은 롤백된다

참고**
애플리케이션 개발에서 중요한 기본 원칙은 모호함을 제거하는 것이다. 개발은 명확해야 한다. 이렇게 커밋을 호출했는데, 내부에서 롤백이 발생한 경우 모호하게 두면 아주 심각한 문제가 발생한다. 이렇게 기대한 결과가 다른 경우 예외를 발생시켜서 명확하게 문제를 알려주는 것이 좋은 설계이다.

만약 이런 상황에서 내부는 롤백하고 외부는 커밋하고 싶을 수 있는데,
이 두개의 트랜잭션을 마치 다른 트랜잭션처럼 분리해서 사용하는 방법을 알아보자.

스프링 트랜잭션 전파7 - REQUIRES_NEW

외부 트랜잭션과 내부 트랜잭션을 완전히 분리해서 사용하는 방법.
커밋과 롤백이 각각 별도로 이뤄진다.
이 방법은 내부 트랜잭션에 문제가 발생해 롤백해도, 외부 트랜잭션에는 영향을 주지 않는다.
반대로 외부 트랜잭션에 문제가 발생해 롤백해도, 내부 트랜잭션에는 영향을 주지 않는다.
먼저 원리를 이해해보자.

• 이렇게 물리 트랜잭션을 분리하려면 내부 트랜잭션을 시작할 때 REQUIRES_NEW 옵션을 사용하면 된다.
• 외부 트랜잭션과 내부 트랜잭션이 각각 별도의 물리 트랜잭션을 가진다.
• 별도의 물리 트랜잭션을 가진다는 뜻은 DB 커넥션을 따로 사용한다는 뜻이다.
• 이 경우 내부 트랜잭션이 롤백되면서 로직 2가 롤백되어도 로직 1에서 저장한 데이터에는 영향을 주지 않는다.
• 최종적으로 로직2는 롤백되고, 로직1은 커밋된다.

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

        log.info("내부 트랜잭션 시작");
        DefaultTransactionAttribute definition = new DefaultTransactionAttribute();
        // 트랜잭션이 있어도 그냥 신규 트랜잭션 만들어버리는 옵션
        definition.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW); // 기본은 PROPAGATION_REQUIRED 인데 이거는 기존 트랜잭션 있으면 그냥참여.
        TransactionStatus inner = txManager.getTransaction(definition);
        log.info("outer.isNewTransaction()={}", outer.isNewTransaction()); // true

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

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

실행 로그

1. 외부 트랜잭션 시작
2. 커넥션 가져오고 isNewTranscation = True 임
3. 내부 트랜잭션 시작, 외부 트랜잭션 잠깐 미뤄놓고 새 트랜잭션을 만듦, manual commit 으로 변경.
4. 커낵션을 획득 (외부 트랜잭션과 다름), isNewTranscation = True 임
5. 내부 트랜잭션 롤백시 롤백 일어나고 커넥션 릴리즈함.
6. 미뤄뒀던 외부 트랜잭션 다시 가져와서 실행함.

요청이 오면 외부 트랜잭션은 커낵션 1번, 내부 트랜잭션은 커낵션 2번!

요청 흐름 - 외부 트랜잭션

1. 요청이 오면 txManager.getTransaction() 를 호출해서 외부 트랜잭션을 시작한다.
2. 트랜잭션 매니저는 데이터소스를 통해 커넥션 생성
3. 생성한 커넥션을 수동 커밋 모드(setAutoCommit(false) )로 설정한다. - 물리 트랜잭션 시작
4. 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관한다.
5. 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus 에 담아서 반환하는데, 여기에 신규 트랜잭션의 여부가 담겨 있다. isNewTransaction 를 통해 신규 트랜잭션 여부를 확인할 수 있다. 트랜 잭션을 처음 시작했으므로 신규 트랜잭션이다.(true )
6. 로직1이 사용되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 트랜잭션이 적용된 커넥션을 획득 해서 사용한다.

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

응답 흐름 - 내부 트랜잭션

1. 로직 2에서 문제가 있어 트랜잭션 매니저를 통해 내부 트랜잭션 롤백
2. 트랜잭션 매니저가 신규 트랜잭션인지 확인하고, 신규트랜잭션 이므로 실제 롤백 호출
3. 내부 트랜잭션이 con2 물리 트랜잭션 롤백함.
   • 트랜잭션 종료되고 con2 커넥션은 커넥션 풀에 반납
   • 이후 con1 의 보류가 끝나 다시 con1 사용

응답 흐름 - 외부 트랜잭션
4. 외부 트랜잭션에서 트랜잭션 메니저를 통해 커밋.
5. 마찬가지로 신규 트랜잭션이므로 실제 커밋 호출
6. 이때 rollbackOnly 설정을 체크한다. rollbackOnly 설정이 없으므로 커밋한다.
7. 본인이 만든 con1 커넥션을 통해 물리 트랜잭션을 커밋한다.
- 트랜잭션이 종료되고, con1 은 종료되거나, 커넥션 풀에 반납된다.

정리
REQUIRES_NEW 옵션을 사용하면 물리 트랜잭션이 명확하게 분리된다.
REQUIRES_NEW 를 사용하면 데이터베이스 커넥션이 동시에 2개 사용된다는 점을 주의해야 한다.

지금은 이론 설명을 위한것이고, 이후에 실제에선 이걸 어떻게 사용하는지 확인해볼 예정.

스프링 트랜잭션 전파8 - 다양한 전파 옵션

스프링은 다양한 트랜잭션 전파 옵션을 제공한다. 전파 옵션에 별도의 설정을 하지 않으면 REQUIRED 가 기본으로 사용된다.
참고로 실무에서는 대부분 REQUIRED 옵션을 사용한다. 그리고 아주 가끔 REQUIRES_NEW 을 사용하고, 나머지는 거의 사용하지 않는다. 그래서 나머지 옵션은 이런 것이 있다는 정도로만 알아두고 필요할 때 찾아보자.

REQUIRED
가장 많이 사용하는 기본 설정이다. 기존 트랜잭션이 없으면 생성하고, 있으면 참여한다.
트랜잭션이 필수라는 의미로 이해하면 된다. (필수이기 때문에 없으면 만들고, 있으면 참여한다.)

• 기존 트랜잭션 없음: 새로운 트랜잭션을 생성한다.
• 기존 트랜잭션 있음: 기존 트랜잭션에 참여한다.

REQUIRES_NEW
항상 새로운 트랜잭션을 생성한다.

• 기존 트랜잭션 없음: 새로운 트랜잭션을 생성한다.
• 기존 트랜잭션 있음: 새로운 트랜잭션을 생성한다.

SUPPORT
트랜잭션을 지원한다는 뜻이다. 기존 트랜잭션이 없으면, 없는대로 진행하고, 있으면 참여한다.

• 기존 트랜잭션 없음: 트랜잭션 없이 진행한다.
• 기존 트랜잭션 있음: 기존 트랜잭션에 참여한다.

NOT_SUPPORT
트랜잭션을 지원하지 않는다는 의미이다.

• 기존 트랜잭션 없음: 트랜잭션 없이 진행한다.
• 기존 트랜잭션 있음: 트랜잭션 없이 진행한다. (기존 트랜잭션은 보류한다)

MANDATORY
의무사항이다. 트랜잭션이 반드시 있어야 한다. 기존 트랜잭션이 없으면 예외가 발생한다.

• 기존 트랜잭션 없음: IllegalTransactionStateException 예외 발생
• 기존 트랜잭션 있음: 기존 트랜잭션에 참여한다.

NEVER
트랜잭션을 사용하지 않는다는 의미이다. 기존 트랜잭션이 있으면 예외가 발생한다. 기존 트랜잭션도 허용하지 않는 강한 부정의 의미로 이해하면 된다.

• 기존 트랜잭션 없음: 트랜잭션 없이 진행한다.
• 기존 트랜잭션 있음: IllegalTransactionStateException 예외 발생

NESTED

• 기존 트랜잭션 없음: 새로운 트랜잭션을 생성한다.
• 기존 트랜잭션 있음: 중첩 트랜잭션을 만든다.
  • 중첩 트랜잭션은 외부 트랜잭션의 영향을 받지만, 중첩 트랜잭션은 외부에 영향을 주지 않는다.
  • 중첩 트랜잭션이 롤백 되어도 외부 트랜잭션은 커밋할 수 있다.
  • 외부 트랜잭션이 롤백 되면 중첩 트랜잭션도 함께 롤백된다.
• 참고
  • JDBC savepoint 기능을 사용한다. DB 드라이버에서 해당 기능을 지원하는지 확인이 필요하다.
  • 중첩 트랜잭션은 JPA에서는 사용할 수 없다.

트랜잭션 전파와 옵션
isolation , timeout , readOnly 는 트랜잭션이 처음 시작될 때만 적용된다. 트랜잭션에 참여하는 경우에는 적용되지 않는다.
예를 들어서 REQUIRED 를 통한 트랜잭션 시작, REQUIRES_NEW 를 통한 트랜잭션 시작 시점에만 적용된다.