[SpringDB2] 스프링 트랜잭션 전파 - 기본

August 8, 2022 8 분 소요

트랜잭션 두 번 사용

이 예제는 트랜잭션1이 완전히 끝나고나서 트랜잭션2를 수행한다.

@Slf4j
@SpringBootTest
public class BasicTxTest {

    @Autowired PlatformTransactionManager txManager;

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

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

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

@TestConfiguration: 해당 테스트에서 필요한 스프링 설정을 추가로 할 수 있다.
DataSourceTransactionManager를 스프링 빈으로 등록했다.

실행 로그

트랜잭션1 시작
Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
Acquired Connection [HikariProxyConnection@1064414847 wrapping conn0] for JDBC transaction
Switching JDBC Connection [HikariProxyConnection@1064414847 wrapping conn0] to manual commit

트랜잭션1 커밋
Initiating transaction commit
Committing JDBC transaction on Connection [HikariProxyConnection@1064414847 wrapping conn0]
Releasing JDBC Connection [HikariProxyConnection@1064414847 wrapping conn0] after transaction
트랜잭션2 시작

Creating new transaction with name [null]: 
PROPAGATION_REQUIRED,ISOLATION_DEFAULT
Acquired Connection [HikariProxyConnection@778350106 wrapping conn0] for JDBC transaction
Switching JDBC Connection [HikariProxyConnection@778350106 wrapping conn0] to manual commit

트랜잭션2 커밋
Initiating transaction commit
Committing JDBC transaction on Connection [HikariProxyConnection@778350106 wrapping conn0]
Releasing JDBC Connection [HikariProxyConnection@778350106 wrapping conn0] after transaction

트랜잭션1

Acquired Connection [HikariProxyConnection@1064414847 wrapping conn0] ...
- 트랜잭션1을 시작하고, 커넥션 풀에서 conn0 커넥션을 획득했다.
Releasing JDBC Connection [HikariProxyConnection@1064414847 wrapping conn0] ...
- 트랜잭션1을 커밋하고, 커넥션 풀에 conn0 커넥션을 반납했다.

트랜잭션2도 비슷하기에 생략..

[주의]
로그를 보면 트랜잭션1과 트랜잭션2가 같은 conn0 커넥션을 사용하는 것을 알 수 있는데, 이는 커넥션 풀 때문에 그런 것이다. 트랜잭션1은 conn0 커넥션을 모두 사용하고, 커넥션 풀에 반납까지 완료했다. 이후에 트랜잭션2가 conn0를 커넥션 풀에서 획득한 것이기 때문에 둘은 완전히 다른 커넥션으로 인지하는 것이 맞다.
Hikari 커넥션 풀에서 커넥션을 획득하면 실제 커넥션을 그대로 반환하는 것이 아니라 내부 관리를 위해 Hikari 프록시 커넥션이라는 객체를 생성해서 반환해준다.(내부에는 실제 커넥션이 포함.) 이 객체의 주소를 확인하면 커넥션 풀에서 획득한 커넥션을 구분할 수 있다.

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

결과적으로 conn0를 통해 커넥션이 재사용 된 것을 확인할 수 있고, HikariProxyConnection@1000000, HikariProxyConnection@2000000을 통해 각각 커넥션 풀에서 커넥션을 조회한 것을 알 수 있다.

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

예제 코드

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

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

예제에서 트랜잭션1은 커밋하고, 트랜잭션2는 롤백한다.
전체 트랜잭션을 묶지 않고 각각 관리했기 때문에, 트랜잭션1에서 저장한 데이터는 커밋되고, 트랜잭션2에서 저장한 데이터는 롤백된다.

실행 로그

트랜잭션1 시작
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

트랜잭션1 커밋
Initiating transaction commit
Committing JDBC transaction on Connection [HikariProxyConnection@1943867171 wrapping conn0]
Releasing JDBC Connection [HikariProxyConnection@1943867171 wrapping conn0] after transaction

트랜잭션2 시작
Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
Acquired Connection [HikariProxyConnection@239290560 wrapping conn0] for JDBC transaction
Switching JDBC Connection [HikariProxyConnection@239290560 wrapping conn0] to manual commit

트랜잭션2 롤백
Initiating transaction rollback
Rolling back JDBC transaction on Connection [HikariProxyConnection@239290560 wrapping conn0]
Releasing JDBC Connection [HikariProxyConnection@239290560 wrapping conn0] after transaction

트랜잭션 전파 기본

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

예시

외부 트랜잭션이 수행중인데, 내부 트랜잭션이 추가로 수행됨

외부 트랜잭션 수행이 끝나기도 전에 내부 트랜잭션이 수행된다.
- 외부 트랜잭션은 처음 시작된 트랜잭션으로 이해하면 된다.

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

물리 트랜잭션, 논리 트랜잭션

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

이러한 논리 트랜잭션 개념을 도입하면 다음과 같은 원칙을 만들 수 있다.

원칙

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

모든 논리 트랜잭션이 커밋 되었으므로 물리 트랜잭션도 커밋된다.

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

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

전파 예제 - Commit

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

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

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

외부 트랜잭션이 수행중인데, 내부 트랜잭션을 추가로 수행했다.
외부 트랜잭션은 처음 수행된 트랜잭션이기 때문에 이 경우 신규 트랜잭션(isNewTransaction=true)이 된다.
내부 트랜잭션을 시작하는 시점에는 이미 외부 트랜잭션이 진행중인 상태이기 때문에, 내부 트랜잭션은 외부 트랜잭션에 참여한다.
트랜잭션 참여
- 내부 트랜잭션이 외부 트랜잭션을 그대로 이어 받아서 따른다는 의미.
- 다른 관점으로 보면 외부 트랜잭션의 범위가 내부 트랜잭션까지 넓어진다는 뜻.
- 정리하면 외부 트랜잭션과 내부 트랜잭션이 하나의 물리 트랜잭션으로 묶이는 것
내부 트랜잭션은 이미 진행중인 외부 트랜잭션에 참여하기 때문에, 이 경우 신규 트랜잭션이 아니다.(isNewTranscation=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 transaction 로그는 내부 트랜잭션이 기존에 존재하는 외부 트랜잭션에 참여한다는 의미이다.
외부 트랜잭션을 시작할 때 DB 커넥션을 통해 물리 트랜잭션을 시작(manual commit)하고, DB 커넥션을 통해 커밋하는 것을 확인할 수 있다. 그런데, 내부 트랜잭션을 시작하거나 커밋할 때는 DB 커넥션을 통해 커밋하는 로그를 확인할 수 없다.
- 정리하면 외부 트랜잭션만 물리 트랜잭션을 시작하고, 커밋한다.
- 만약, 내부 트랜잭션이 실제 물리 트랜잭션을 커밋해서 트랜잭션이 끝나버리면, 트랜잭션을 처음 시작한 외부 트랜잭션까지 이어갈 수 없기 때문이다.
스프링은 이렇게 여러 트랜잭션이 함께 사용되는 경우, 처음 트랜잭션을 시작한 외부 트랜잭션이 실제 물리 트랜잭션을 관리하도록 한다.
- 이를 통해 트랜잭션 중복 커밋 문제를 해결한다.

트랜잭션 전파 흐름

요청 흐름 - 외부 트랜잭션

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

요청 흐름 - 내부 트랜잭션

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

응답 흐름 - 내부 트랜잭션

12.로직2가 끝나고, 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋한다.
13.트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다.
- 이 경우 신규 트랜잭션이 아니기 때문에 실제 커밋을 호출하지 않는다.
- 만약, 여기서 실제 커넥션에 커밋이나 롤백을 호출한다면, 물리 트랜잭션이 끝나버린다.
- 아직 트랜잭션이 끝난 것이 아니기 때문에 실제 커밋을 호출하면 안된다.

응답 흐름 - 외부 트랜잭션

14.로직1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋한다.
15.트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다.
- 외부 트랜잭션은 신규 트랜잭션이기 때문에 DB 커넥션에 실제 커밋을 호출한다.

핵심 정리

핵심은 트랜잭션 매니저에 커밋을 호출한다고 해서 항상 실제 커넥션에 물리 커밋이 발생하지는 않는다는 점이다.
신규 트랜잭션인 경우에만 실제 커넥션을 사용해서 물리 커밋과 롤백을 수행한다.
트랜잭션이 내부에서 추가로 사용되면, 트랜잭션 매니저를 통해 논리 트랜잭션을 관리하고, 모든 논리 트랜잭션이 커밋되면 물리 트랜잭션이 커밋된다고 이해하면 된다.

전파 예제 - 외부 롤백

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

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

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

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

실행 결과

외부 트랜잭션 시작
Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
Acquired Connection [HikariProxyConnection@461376017 wrapping conn0] for JDBC transaction
Switching JDBC Connection [HikariProxyConnection@461376017 wrapping conn0] to manual commit

내부 트랜잭션 시작
Participating in existing transaction
내부 트랜잭션 커밋

외부 트랜잭션 롤백
Initiating transaction rollback
Rolling back JDBC transaction on Connection [HikariProxyConnection@461376017 wrapping conn0]
Releasing JDBC Connection [HikariProxyConnection@461376017 wrapping conn0] after transaction

외부 트랜잭션이 물리 트랜잭션을 시작하고, 롤백하는 것을 확인할 수 있다.
내부 트랜잭션은 물리 트랜잭션에 관여하지 않는다.

응답 흐름

내부 트랜잭션

1.로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋.
2.트랜잭션 매니저는 커밋 시점에 신규 트랜잭션이 아니기 때문에 실제 커밋을 호출하지 않는다.

외부 트랜잭션

3.로직1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 롤백한다.
4.외부 트랜잭션은 신규 트랜잭션이기 때문에 트랜잭션 매니저는 DB 커넥션에 실제 롤백을 호출한다.
5.실제 데이터베이스에 롤백이 반영되고, 물리 트랜잭션도 끝난다.

전파 예제 - 내부 롤백

@Test
void inner_rollback() {
    log.info("외부 트랜잭션 시작");
    TransactionStatus outer = txManager.getTransaction(new DefaultTransactionDefinition());
    
    log.info("내부 트랜잭션 시작");
    TransactionStatus inner = txManager.getTransaction(new DefaultTransactionDefinition());
    log.info("내부 트랜잭션 롤백");
    txManager.rollback(inner);
    
    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 rollback-only
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 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 런타임 예외를 던진다. 그래서 커밋을 시도했지만, 기대하지 않은 롤백이 발생했다는 것을 명확하게 알려준다.

정리

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

<출처 : 인프런 - 스프링 DB 2편 : 데이터 접근 활용 기술(김영한)>

Twitter Facebook LinkedIn

[SpringDB2] 스프링 트랜잭션 전파 - 기본

트랜잭션 두 번 사용

트랜잭션1

예제 코드

트랜잭션 전파 기본

예시

원칙

전파 예제 - Commit

트랜잭션 전파 흐름

핵심 정리

전파 예제 - 외부 롤백

응답 흐름

전파 예제 - 내부 롤백

응답 흐름

정리

공유하기

댓글남기기

참고

[독서] 돈의속성

[독서] 부자 아빠 가난한 아빠

[독서] 부자 아빠 가난한 아빠

[취업] SKCT 후기