Spring에서의 트랜잭션 전파1

hoyong.eom·2023년 9월 6일
Spring트랜잭션
0

스프링

목록 보기
39/59
post-thumbnail

Spring

스프링 트랜잭션 전파1 - 커밋, 롤백

우선 트랜잭션 관련 로그를 확인하기 위해서 application.properties에 아래의 설정을 추가한다.

logging.level.org.springframework.transaction.interceptor=TRACE
logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManager=
DEBUG
#JPA log
logging.level.org.springframework.orm.jpa.JpaTransactionManager=DEBUG
logging.level.org.hibernate.resource.transaction=DEBUG
#JPA SQL
logging.level.org.hibernate.SQL=DEBUG

우선 아래의 코드는 트랜잭션을 사용한 간단한 예제이다.


    @Autowired
    PlatformTransactionManager txManager;

    @TestConfiguration
    static class Config {
        @Bean
        public PlatformTransactionManager transactionManager(DataSource dataSource) {
            return new DataSourceTransactionManager(dataSource);
        }
    }

    @Test
    void commit() {
        log.info("트랜잭션 시작");
        TransactionStatus status = txManager.getTransaction(new DefaultTransactionAttribute());

        log.info("트랜잭션 커밋 시작");
        txManager.commit(status);
        log.info("트랜잭션 커밋 완료");
    }

    @Test
    void rollback() {
        log.info("트랜잭션 시작");
        TransactionStatus status = txManager.getTransaction(new DefaultTransactionAttribute());

        log.info("트랜잭션 롤백 시작");
        txManager.rollback(status);
        log.info("트랜잭션 롤백 완료");
    }

    @Test
    void double_commit() {
        log.info("트랜잭션1 시작");
        TransactionStatus tx1 = txManager.getTransaction(new DefaultTransactionAttribute());
        log.info("트랜잭션1 커밋");
        txManager.commit(tx1);

        log.info("트랜잭션2 시작");
        TransactionStatus tx2 = txManager.getTransaction(new DefaultTransactionAttribute());
        log.info("트랜잭션2 커밋");
        txManager.commit(tx2);
    }

    @Test
    void double_commit_rollback() {
        log.info("트랜잭션1 시작");
        TransactionStatus tx1 = txManager.getTransaction(new DefaultTransactionAttribute());
        log.info("트랜잭션1 커밋");
        txManager.commit(tx1);

        log.info("트랜잭션2 시작");
        TransactionStatus tx2 = txManager.getTransaction(new DefaultTransactionAttribute());
        log.info("트랜잭션2 롤백");
        txManager.rollback(tx2);
    }

    @Test
    void inner_commit() {
        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.commit(outer);

    }

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

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

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

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

        log.info("내부 트랜잭션 시작");
        TransactionStatus inner = txManager.getTransaction(new DefaultTransactionAttribute());
        log.info("내부 트랜잭션 롤백");
        txManager.rollback(inner); //rollback-only 표시

        log.info("외부 트랜잭션 커밋");
        assertThatThrownBy(() -> txManager.commit(outer))
                .isInstanceOf(UnexpectedRollbackException.class);
    }

    @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);
        TransactionStatus inner = txManager.getTransaction(definition);
        log.info("inner.isNewTransaction()={}", inner.isNewTransaction()); //true

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

        log.info("외부 트랜잭션 커밋");
        txManager.commit(outer); //커밋
    }
  • @TestConfiguration : 해당 테스트에 필요한 스프링 설정을 추가로 할 수 있다.
  • DataSourceTransactionManager : PlatformTransactionManager의 구현체중 하나인 DataSourceTransactionManager를 스프링빈으로 등록한다.
  • txManager.getTransaction(new DefaultTrasactionAttribute())로 트랜잭션을 시작한다.

아래는 트랜잭션 로그이다

2023-09-06 22:10:04.915  INFO 8132 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션1 시작
2023-09-06 22:10:04.916 DEBUG 8132 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2023-09-06 22:10:04.917 DEBUG 8132 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Acquired Connection [HikariProxyConnection@488624810 wrapping conn0: url=jdbc:h2:mem:3ab257a9-af33-4eb9-8162-4a660efc5c0b user=SA] for JDBC transaction
2023-09-06 22:10:04.920 DEBUG 8132 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Switching JDBC Connection [HikariProxyConnection@488624810 wrapping conn0: url=jdbc:h2:mem:3ab257a9-af33-4eb9-8162-4a660efc5c0b user=SA] to manual commit
2023-09-06 22:10:04.921  INFO 8132 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션1 커밋
2023-09-06 22:10:04.921 DEBUG 8132 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Initiating transaction commit
2023-09-06 22:10:04.921 DEBUG 8132 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Committing JDBC transaction on Connection [HikariProxyConnection@488624810 wrapping conn0: url=jdbc:h2:mem:3ab257a9-af33-4eb9-8162-4a660efc5c0b user=SA]
2023-09-06 22:10:04.922 DEBUG 8132 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Releasing JDBC Connection [HikariProxyConnection@488624810 wrapping conn0: url=jdbc:h2:mem:3ab257a9-af33-4eb9-8162-4a660efc5c0b user=SA] after transaction
2023-09-06 22:10:04.922  INFO 8132 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션2 시작
2023-09-06 22:10:04.923 DEBUG 8132 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2023-09-06 22:10:04.923 DEBUG 8132 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Acquired Connection [HikariProxyConnection@933346995 wrapping conn0: url=jdbc:h2:mem:3ab257a9-af33-4eb9-8162-4a660efc5c0b user=SA] for JDBC transaction
2023-09-06 22:10:04.923 DEBUG 8132 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Switching JDBC Connection [HikariProxyConnection@933346995 wrapping conn0: url=jdbc:h2:mem:3ab257a9-af33-4eb9-8162-4a660efc5c0b user=SA] to manual commit
2023-09-06 22:10:04.924  INFO 8132 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션2 커밋

위 로그를 보면 트랜잭션1과 트랜잭션2가 같은 conn0 커넥션을 사용한다. 이것은 중간에 커넥션풀 때문에 그런것이다. 트랜잭션1은 conn0 커넥션을 모두 사용하고 커넥션 풀에 반납까지 완료한다. 이후에 트랜잭션2가 conn0을 커넥션 풀에서 획득한다. 따라서 둘은 완전히 다른 커넥션으로 인지하는것이 맞다.

이 둘을 구분하기 위해서 히카리 커넥션 풀에서 커넥션을 획득하면 실제 커넥션을 그대로 반환하는것이 아니라 내부 관리를 위해 히카리 프록시 커넥션이라는 객체를 생성해서 반환한다. 내부에는 실제 커넥션이 포함되어 있다.
이 객체의 주소를 확인하면 커넥션풀에서 획득한 커넥션을 구분할 수 있다.

트랜잭션1: Acquired Connection [HikariProxyConnection@1000000 wrapping conn0]
트랜잭션2: Acquired Connection [HikariProxyConnection@2000000 wrapping conn0]

  • 트랜잭션이 각각 수행되면서 사용되는 DB 커넥션도 다르다.
  • 이 경우 트랜잭션을 각자 관리하기 떄문에 전체 트랜잭션을 묶을 수 없다.

스프링 트랜잭션 전파 기본

트랜잭션을 각각 사용하는것이 아니라 트랜잭션을 이미 진행중인데, 여기에 추가로 트랜잭션을 수행하려면 어떻게 될까?
기존 트랜잭션과 별도의 트랜잭션을 진행해야할까? 아니면 기존 트랜잭션을 그대로 이어받아서 트랜잭션을 수행해야할까?
이런 경우 어떻게 동작할지 결정하는것을 트랜잭션 전파(propagation)라 한다.

  • 외부 트랜잭션이 수행중이고 아직 끝나지 않았는데 내부 트랜잭션이 수행된다.

  • 스프링 이 경우 외부 트랜잭션과 내부 트랜잭션을 묶어서 하나의 트랜잭션을 만들어준다. 내부 트랜잭션이 외부 트랜잭션에 참여하는것이다. 이것이 기본 동작이고 옵션을 통해 다른 동작 방식도 선택할 수 있다.

  • 스프링은 이해를 돕기 위해 논리 트랜잭션과 물리 트랜잭션이라는 개념을 나눈다.
  • 논리 트랜잭션들을 하나의 물리 트랜잭션으로 묶인다.
  • 물리 트랜잭션은 원리가 이해하는 실제 데이터베이스에 적용되는 트랜잭션을 뜻한다. 실제 커넥션을 통해 트랜잭션을 시작(setAutoCommit(false))하고, 실제 커넥션을 통해서 커밋, 롤백하는 단위이다.
  • 논리 트랜잭션은 트랜잭션 매니저를 통해 트랜잭션을 사용하는 단위이다.
  • 논리 트랜잭션 개념은 트랜잭션이 진행되는 중에 내부에 추가로 트랜잭션을 사용하는 경우에 나타난다. 단순히 트랜잭션이 하나인 경우 둘을 구분하지 않는다.( 더 정확히는 REQUIRED 전파 옵션을 사용하는 경우에 나타난다.)

중요 원칙

  • 모든 논리 트랜잭션이 커밋되어야 물리 트랜잭션이 커밋된다.
  • 하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션은 롤백된다.
  • 모든 논리 트랜잭션이 커밋되었으므로 물리 트랜잭션도 커밋된다.

  • 외부 논리 트랜잭션이 롤백되었으므로 물리 트랜잭션은 롤백된다.

  • 내부 논리 트랜잭션이 롤백되었으므로 물리 트랜잭션은 롤백된다.

스프링 트랜잭션 전파 - 예제

    @Test
    void inner_commit() {
        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.commit(outer);

    }
  • 외부 트랜잭션이 수행중인데, 내부 트랜잭션을 추가로 수행했다.
  • 외부 트랜잭션은 처음 수행된 트랜잭션이다. 이 경우 신규 트랜잭션(isNewTransaction = true)가 되며 이 값은 TransactionStatus에서 확인할 수 있다.
  • 내부 트랜잭션을 시작하는 시점에는 이미 외부 트랜잭션이 진행중인 상태이다. 이 경우 내부 트랜잭션은 외부 트랜잭션에 참여한다.
  • 트랜잭션 참여
    - 내부 트랜잭션이 외부 트랜잭션에 참여한다는 뜻은 내부 트랜잭션이 외부 트랜잭션을 그대로 이어 받아서 따른다는 뜻이다.
    • 다른 관점으로 보면 외부 트랜잭션의 범위가 내부 트랜잭션까지 넓어진다는 뜻이다.
    • 외부에서 시작된 물리적인 트랜잭션의 범위가 내부 트랜잭션까지 넓어진다는 뜻이다.
    • 정리하면 외부 트랜잭션과 내부 트랜잭션이 하나의 물리 트랜잭션으로 묶인다.
  • 내부 트랜잭션은 이미 진행중인 외부 트랜잭션에 참여한다. 이 경우 신규 트랜잭션은 아니다.( isNewTransaction = false)

위 예제에서는 외부 트랜잭션과 내부 트랜잭션이 하나의 물리 트랜잭션으로 묶인다고 했다. 그런데 코드를 잘 보면 커밋을 두번이나 호출한다. 트랜잭션을 생각해보면 하나의 커넥션에 커밋은 한번만 호출할 수 있다.
커밋이나 롤백을 하면 해당 트랜잭션이 끝나버린다.

외부 트랜잭션 시작
Creating new transaction with name [null]: 
PROPAGATION_REQUIRED,ISOLATION_DEFAULT
Acquired Connection [HikariProxyConnection@1943867171 wrapping conn0] for JDBC 
transaction
Switching JDBC Connection [HikariProxyConnection@1943867171 wrapping conn0] to 
manual commit
outer.isNewTransaction()=true
내부 트랜잭션 시작
Participating in existing transaction
inner.isNewTransaction()=false
내부 트랜잭션 커밋
외부 트랜잭션 커밋
Initiating transaction commit
Committing JDBC transaction on Connection [HikariProxyConnection@1943867171 
wrapping conn0]
Releasing JDBC Connection [HikariProxyConnection@1943867171 wrapping conn0] 
after transaction
  • 내부 트랜잭션을 시작 할때 Participating in existing transation이라는 메시지를 확인할 수 있다. 이 메시지는 내부 트랜잭션이 기존에 존재하는 외부 트랜잭션에 참여한다는 뜻이다.
  • 실행 결과를 보면 외부 트랜잭션을 시작하거나 커밋할때는 DB 커넥션을 통한 물리 트랜잭션을 시작(manual commit)하고, DB 커넥션을 통해 커밋하는것을 확인할 수 있다. 그런데 내부 트랜잭션을 시작하거나 커밋할때는 DB 커넥션을 통해 커밋하는 로그를 전혀 확인할 수 없다.
  • 정리하면 외부 트랜잭션만 물리 트랜잭션을 시작하고 커밋한다.
  • 만약 내부 트랜잭션이 실제 물리 트랜잭션을 커밋하면 트랜잭션이 끝나버리기 때문에 트랜잭션을 처음 시작한 외부 트랜잭션까지 이어갈 수 없다. 따라서 내부 트랜잭션은 DB 커넥션을 통한 물리 트랜잭션을 커밋하면 안된다.
  • 스프링은 이렇게 여러 트랜잭션이 함께 사용되는 경우 처음 트랜잭션을 시작한 외부 트랜잭션이 실제 물리 트랜잭션을 관리하도록 한다. 이를 통해 트랜잭션 중복 커밋 문제를 해결한다.


요청 흐름 - 외부 트랜잭션

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

요청 흐름 - 내부 트랜잭션

    1. txManager.getTransaction()를 호출해서 내부 트랜잭션을 시작한다.
    1. 트랜잭션 매니저는 트랜잭션 동기화 매니저를 통해서 기존 트랜잭션이 존재하는 확인한다.
    1. 기존 트랜잭션이 존재하므로 기존 트랜잭션에 참여한다. 기존 트랜잭션에 참여한다는 뜻은 사실 아무것도 하지 않는다는 뜻이다.
      - 이미 기존 트랜잭션인 외부 트랜잭션에서 물리 트랜잭션을 시작했다. 그리고 물리 트랜잭션이 시작된 커넥션을 트랜잭션 동기화 매니저에 담아두었다.
    • 따라서 이미 물리 트랜잭션이 진행중이므로 그냥 두면 이후 로직이 기존에 시작된 트랜잭션을 자연스럽게 사용하게 된다.
    • 이후 로직은 자연스럽게 트랜잭션 동기화 매니저에 보관된 기존 커넥션을 사용하게 된다.
    1. 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus에 담아서 반환하는데, 여기에서 isNewTransaction를 통해 신규 트랜잭션 여부를 확인할 수 있다. 여기서는 기존 트랜잭션에 참여했기 때문에 신규 트랜잭션이 아니다.
    1. 로직2가 사용되고 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 외부 트랜잭션이 보관한 커넥션을 획득해서 사용한다.

      응답 흐름 - 내부 트랜잭션
    1. 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋한다.
    1. 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 이 경우 신규 트랜잭션이 아니기 때문에 실제 커밋을 호출하지 않는다. 이 부분이 중요한데 실제 커넥션에 커밋이나 롤백을 호출하면 물리 트랜잭션이 끝나버린다. 아직 트랜잭션이 끝날것이 아니기 때문에 실제 커밋을 호출하면 안된다. 물리 트랜잭션은 외부 트랜잭션이 종료할때까지 이어져야한다.

응답 흐름 - 외부 트랜잭션

    1. 로직1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋한다.
    1. 트랜잭션 매니저는 커밋시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 외부 트랜잭션은 신규 트랜잭션이다. 따라서 DB 커넥션에 실제 커밋을 호출한다.
    1. 트랜잭션 매니저에 커밋하는것이 논리적인 커밋이라면, 실제 커넥션에 커밋하는것을 물리 커밋이라 할 수 있다. 실제 데이터베이스에 커밋이 반영되고 물리 트랜잭션도 끝난다.

핵심 정리

  • 여기서 핵심은 트랜잭션 매니저에 커밋을 호출한다고 해서 항상 실제 커넥션에 물리 커밋이 발생하지는 않는다는 점이다.
  • 신규 트랜잭션인 경우에만 실제 커넥션을 사용해서 물리 커밋과 롤백을 수행한다. 신규 트랜잭션이 아니면 실제 물리 커넥션을 사용하지 않는다.
  • 이렇게 트랜잭션이 내부에서 추가로 사용되면 트랜잭션 매니저에 커밋하는것이 항상 물리 커밋으로 이어지지 않는다.그래서 이 경우 논리 트랜잭션과 물리 트랜잭션으로 나누게 된다. 또는 외부 트랜잭션과 내부 트랜잭션으로도 나누기도 한다.
  • 트랜잭션이 내부에서 추가로 사용되면 트랜잭션 매니저를 통해 논리 트랜잭션을 관리하고 모든 논리 트랜잭션이 커밋되면 물리 트랜잭션이 커밋된다고 이해하면 된다.

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


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


응답 흐름 - 내부 트랜잭션

    1. 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋한다.
    1. 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 이 경우 신규 트랜잭션이 아니기 때문에 실제 커밋을 호출하지 않는다. 이 부분이 중요한데, 실제 커넥션에 커밋이나 롤백을 호출하면 물리 트랜잭션이 끝나버린다. 아직 트랜잭션이 끝난 것이 아니기 때문에 실제 커밋을 호출하면 안된다. 물리 트랜잭션은 외부 트랜잭션이 종료할때 까지 이어져야한다.

    응답 흐름 - 외부 트랜잭션

    1. 로직1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 롤백한다.
    1. 트랜잭션 매니저는 롤백 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 외부 트랜잭션은 신규 트랜잭션이다. 따라서 DB커넥션에 실제 롤백을 호출한다.
    1. 트랜잭션 매니저에 롤백하는 것이 논리적인 롤백이라면 실제 커넥션에 롤백하는것을 물리 롤백이라 할 수있다. 실제 데이터베이스에 롤백이 반영되고 물리 트랜잭션도 끝난다.

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


이 상황은 겉으로 보기에는 단순하지만 실제로는 단순하지 않는다. 내부 트랜잭션을 롤백했지만 내부 트랜잭션은 물리 트랜잭션에 영향을 주지 않는다. 그런데 외부 트랜잭션에 커밋을 해버린다.지금까지는 외부 트랜잭션만 물리 트랜잭션에 영향을 주기 때문에 물리 트랜잭션이 커밋될것 같다.

하지만 실제로는 외부 트랜잭션이 커밋할때 UnexpectedRollbackException이 발생한다.

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

        log.info("내부 트랜잭션 시작");
        TransactionStatus inner = txManager.getTransaction(new DefaultTransactionAttribute());
        log.info("내부 트랜잭션 롤백");
        txManager.rollback(inner); //rollback-only 표시

        log.info("외부 트랜잭션 커밋");
        assertThatThrownBy(() -> txManager.commit(outer))
                .isInstanceOf(UnexpectedRollbackException.class);
    }

외부 트랜잭션 시작
Creating new transaction with name [null]: 
PROPAGATION_REQUIRED,ISOLATION_DEFAULT
Acquired Connection [HikariProxyConnection@220038608 wrapping conn0] for JDBC 
transaction
Switching JDBC Connection [HikariProxyConnection@220038608 wrapping conn0] to 
manual commit
내부 트랜잭션 시작
Participating in existing transaction
내부 트랜잭션 롤백
Participating transaction failed - marking existing transaction as rollbackonly
Setting JDBC transaction [HikariProxyConnection@220038608 wrapping conn0] 
rollback-only
외부 트랜잭션 커밋
Global transaction is marked as rollback-only but transactional code requested 
commit
Initiating transaction rollback
Rolling back JDBC transaction on Connection [HikariProxyConnection@220038608 
wrapping conn0]
Releasing JDBC Connection [HikariProxyConnection@220038608 wrapping conn0] 
after transaction
  • 외부 트랜잭션 시작
    - 물리 트랜잭션을 시작한다.
  • 내부 트랜잭션 시작
    - Participating in existing transaction
    • 기존 트랜잭션에 참여한다.
  • 내부 트랜잭션 롤백
    - Participating transcation failed - marking existing transaction as rollback-only
    • 내부 트랜잭션을 롤백하면 실제 물리 트랜잭션은 롤백하지 않는다. 대신에 기존 트랜잭션을 롤백 전용으로 표시한다.
  • 외부 트랜잭션 커밋
    - 외부 트랜잭션을 커밋한다.
    • Global transaction is marked as rollback-only
    • 커밋을 호출했지만 전체 트랜잭션이 롤백 전용으로 표시되어 있다. 따라서 물리 트랜잭션을 롤백한다.


응답 흐름 - 내부 트랜잭션

    1. 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백한다.(로직2에 문제가 있어서 롤백한다고 가정한다.)
    1. 트랜잭션 매니저를 롤백시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 이 경우 신규 트랜잭션이 아니기 때문에 실제 롤백을 호출 하진 않는다. 다만, 실제 커넥션에 롤백을 호출하면 물리 트랜잭션이 끝나버린다. 아직 트랜잭션이 끝난 것이 아니기 떄문에 실제 롤백을 호출하면 안된다.
      물리 트랜잭션은 외부 트랜잭션을 종료할떄까지 이어져야한다.
    1. 내부 트랜잭션은 물리 트랜잭션을 롤백하지 않는 대신에 트랜잭션 동기화 매니저에 rollbackOnly=true라고 표시해둔다.

응답 흐름 - 외부 트랜잭션

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

정리

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

스프링 트랜잭션 전파 - 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);
        TransactionStatus inner = txManager.getTransaction(definition);
        log.info("inner.isNewTransaction()={}", inner.isNewTransaction()); //true

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

        log.info("외부 트랜잭션 커밋");
        txManager.commit(outer); //커밋
    }
  • 내부 트랜잭션을 시작할때 전파 옵션인 propagationBehavior에 PROPAGATION_REQUIRES_NEW 옵션을 준다.
  • 이 전파 옵션을 사용하면 내부 트랜잭션을 시작할때 기존 트랜잭션에 참여하는게 아니라 새로운 물리 트랜잭션을 만들어 시작하게 된다.


요청 흐름 - 외부 트랜잭션

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

요청 흐름 - 내부 트랜잭션

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

업로드중..
응답 흐름 - 내부 트랜잭션

    1. 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백한다. (로직2에 문제가 있어서 롤백한다고 가정한다.)
    1. 트랜잭션 매니저는 롤백 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 현재 내부 트랜잭션은 신규 트랜잭션이다. 따라서 실제 롤백을 호출한다.
    1. 내부 트랜잭션이 con2 물리 트랜잭션을 롤백한다. 트랜잭션이 종료되고, con2 는 종료되거나, 커넥션 풀에 반납된다. 이후에 con1 의 보류가 끝나고, 다시 con1 을 사용한다.

응답 흐름 - 외부 트랜잭션

    1. 외부 트랜잭션에 커밋을 요청한다.
    1. 외부 트랜잭션은 신규 트랜잭션이기 때문에 물리 트랜잭션을 커밋한다.
    1. 이때 rollbackOnly 설정을 체크한다. rollbackOnly 설정이 없으므로 커밋한다.
    1. 본인이 만든 con1 커넥션을 통해 물리 트랜잭션을 커밋한다.
      트랜잭션이 종료되고, con1 은 종료되거나, 커넥션 풀에 반납된다

핵심 정리

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

스프링 트랜잭션 전파 - 전파 옵션

스프링은 다양한 옵션을 제공한다. 전파 옵션에 별도의 설정을 하지 않으면 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 를 통한 트랜잭션 시작 시점에만 적용된다

참고

아래의 강의를 공부하여 정리한 내용입니다.
김영한님의 스프링 DB2

profile
hoyong.eom
Hello
이전 포스트

Spring의 트랜잭션 추상화, 커밋, 롤백

다음 포스트

Spring에서의 ThreadLocal

0개의 댓글