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

YuDeokRin · 2025-01-20T13:52:44Z

YuDeokRin
Jan 20, 2025
Maintainer

스프링 트랜잭션 전파1 - 기본

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

스프링 트랜잭션 코드를 통해 기본 원리를 학습해보자.
BasicTxTest - Config
- @TestConfiguration : 해당 테스트에서 필요한 스프링 설정 추가
- DataSourceTransactionManager를 스프링 빈으로 등록
- PlatformTransactionManager를 주입 바등면 방금 등록한 DataSourceTransactionManager가 주입된다.

@SpringBootTest
@Slf4j
public class BasicTxTest {

    @Autowired
    PlatformTransactionManager txManager;

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

BasicTxTest - commit 테스트

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

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

로그 확인 (결과 확인)

2025-01-20T20:12:40.435+09:00  INFO 47128 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션 커밋 시작
2025-01-20T20:12:40.435+09:00 DEBUG 47128 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Initiating transaction commit
2025-01-20T20:12:40.436+09:00 DEBUG 47128 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Committing JDBC transaction on Connection [HikariProxyConnection@1772902226 wrapping conn0: url=jdbc:h2:mem:9c7d2060-91ca-4fbc-aabb-64d950e34180 user=SA]
2025-01-20T20:12:40.436+09:00 DEBUG 47128 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Releasing JDBC Connection [HikariProxyConnection@1772902226 wrapping conn0: url=jdbc:h2:mem:9c7d2060-91ca-4fbc-aabb-64d950e34180 user=SA] after transaction
2025-01-20T20:12:40.436+09:00  INFO 47128 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션 커밋 완료

BasicTxTest - rollback 테스트

@Test
@DisplayName("트랜잭션 롤백 테스트")
public void rollback() {
        log.info("트랜잭션 시작 ");
        TransactionStatus status = txManager.getTransaction(new DefaultTransactionDefinition()); // 트랜잭션 시작

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

2025-01-20T20:19:20.818+09:00  INFO 47149 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션 롤백 시작
2025-01-20T20:19:20.819+09:00 DEBUG 47149 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Initiating transaction rollback
2025-01-20T20:19:20.819+09:00 DEBUG 47149 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Rolling back JDBC transaction on Connection [HikariProxyConnection@1086342015 wrapping conn0: url=jdbc:h2:mem:8db481b5-69e0-45e9-8cb9-b0d15033f58e user=SA]
2025-01-20T20:19:20.819+09:00 DEBUG 47149 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Releasing JDBC Connection [HikariProxyConnection@1086342015 wrapping conn0: url=jdbc:h2:mem:8db481b5-69e0-45e9-8cb9-b0d15033f58e user=SA] after transaction
2025-01-20T20:19:20.819+09:00  INFO 47149 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션 롤백 완료

2️⃣ 스프링 트랜잭션 전파2 - 트랜잭션 두 번 사용

트랜잭션을 두 번 사용하는 방법과 두번 사용하면서 어떻게 내부가 되어있는지 확인해보자.
double_commit() - BasicTxTest 추가

@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);
}

로그 결과

2025-01-20T21:51:55.316+09:00  INFO 47431 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션1 시작
2025-01-20T21:51:55.317+09:00 DEBUG 47431 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2025-01-20T21:51:55.318+09:00 DEBUG 47431 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Acquired Connection [HikariProxyConnection@546704209 wrapping conn0: url=jdbc:h2:mem:09d4fba2-e9fb-47f0-aa09-b53d0c3e8f5b user=SA] for JDBC transaction
2025-01-20T21:51:55.319+09:00 DEBUG 47431 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Switching JDBC Connection [HikariProxyConnection@546704209 wrapping conn0: url=jdbc:h2:mem:09d4fba2-e9fb-47f0-aa09-b53d0c3e8f5b user=SA] to manual commit
2025-01-20T21:51:55.319+09:00  INFO 47431 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션1 커밋
2025-01-20T21:51:55.319+09:00 DEBUG 47431 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Initiating transaction commit
2025-01-20T21:51:55.320+09:00 DEBUG 47431 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Committing JDBC transaction on Connection [HikariProxyConnection@546704209 wrapping conn0: url=jdbc:h2:mem:09d4fba2-e9fb-47f0-aa09-b53d0c3e8f5b user=SA]
2025-01-20T21:51:55.320+09:00 DEBUG 47431 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Releasing JDBC Connection [HikariProxyConnection@546704209 wrapping conn0: url=jdbc:h2:mem:09d4fba2-e9fb-47f0-aa09-b53d0c3e8f5b user=SA] after transaction
2025-01-20T21:51:55.320+09:00  INFO 47431 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션2 시작
2025-01-20T21:51:55.320+09:00 DEBUG 47431 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2025-01-20T21:51:55.320+09:00 DEBUG 47431 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Acquired Connection [HikariProxyConnection@1076326519 wrapping conn0: url=jdbc:h2:mem:09d4fba2-e9fb-47f0-aa09-b53d0c3e8f5b user=SA] for JDBC transaction
2025-01-20T21:51:55.320+09:00 DEBUG 47431 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Switching JDBC Connection [HikariProxyConnection@1076326519 wrapping conn0: url=jdbc:h2:mem:09d4fba2-e9fb-47f0-aa09-b53d0c3e8f5b user=SA] to manual commit
2025-01-20T21:51:55.320+09:00  INFO 47431 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션2 커밋
2025-01-20T21:51:55.320+09:00 DEBUG 47431 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Initiating transaction commit
2025-01-20T21:51:55.320+09:00 DEBUG 47431 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Committing JDBC transaction on Connection [HikariProxyConnection@1076326519 wrapping conn0: url=jdbc:h2:mem:09d4fba2-e9fb-47f0-aa09-b53d0c3e8f5b user=SA]
2025-01-20T21:51:55.321+09:00 DEBUG 47431 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Releasing JDBC Connection [HikariProxyConnection@1076326519 wrapping conn0: url=jdbc:h2:mem:09d4fba2-e9fb-47f0-aa09-b53d0c3e8f5b user=SA] after transaction

➡️ 트랜잭션1

Acquired Connection [HikariProxyConnection@546704209 wrapping conn0: url=jdbc:h2:mem:09d4fba2-e9fb-47f0-aa09-b53d0c3e8f5b user=SA] for JDBC transaction

트랜잭션1을 시작하고 커넥션 풀에서 conn0 커넥션을 획득했다. ( conn0은 물리적 결합)

Releasing JDBC Connection [HikariProxyConnection@546704209 wrapping conn0: url=jdbc:h2:mem:09d4fba2-e9fb-47f0-aa09-b53d0c3e8f5b user=SA] after transaction

트랜잭션1을 커밋하고, 커넥션 풀에 conn0 커넥션을 반납했다.

➡️ 트랜잭션2

Acquired Connection [HikariProxyConnection@1076326519 wrapping conn0: url=jdbc:h2:mem:09d4fba2-e9fb-47f0-aa09-b53d0c3e8f5b user=SA] for JDBC transaction

트랜잭션1을 시작하고 커넥션 풀에서 conn0 커넥션을 획득했다. ( conn0은 물리적 결합)

Releasing JDBC Connection [HikariProxyConnection@1076326519 wrapping conn0: url=jdbc:h2:mem:09d4fba2-e9fb-47f0-aa09-b53d0c3e8f5b user=SA] after transaction

트랜잭션2을 커밋하고, 커넥션 풀에 conn0 커넥션을 반납했다.

⚠️주의!

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

➡️ 질문 ? 그 둘의 커넥션을 구분할 수 있는 다른 방법은 없을까 ?

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

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

서로 다른 주소를 가지고 있다. 따라서 둘이 다른 것이다.

트랜잭션이 각각 수행되면서 사용되는 DB 커넥션도 각각 다르다.
커넥션풀 사용 X

커넥션풀 사용할때 그림
double_commit_rollback() - 실행 로그

@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);
}

로그 결과

2025-01-20T22:15:08.324+09:00  INFO 47605 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션1 시작
2025-01-20T22:15:08.324+09:00 DEBUG 47605 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2025-01-20T22:15:08.326+09:00 DEBUG 47605 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Acquired Connection [HikariProxyConnection@127618303 wrapping conn0: url=jdbc:h2:mem:bc33bbb6-f38a-47ac-b20c-43b1dfc55fec user=SA] for JDBC transaction
2025-01-20T22:15:08.327+09:00 DEBUG 47605 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Switching JDBC Connection [HikariProxyConnection@127618303 wrapping conn0: url=jdbc:h2:mem:bc33bbb6-f38a-47ac-b20c-43b1dfc55fec user=SA] to manual commit
2025-01-20T22:15:08.327+09:00  INFO 47605 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션1 커밋
2025-01-20T22:15:08.327+09:00 DEBUG 47605 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Initiating transaction commit
2025-01-20T22:15:08.327+09:00 DEBUG 47605 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Committing JDBC transaction on Connection [HikariProxyConnection@127618303 wrapping conn0: url=jdbc:h2:mem:bc33bbb6-f38a-47ac-b20c-43b1dfc55fec user=SA]
2025-01-20T22:15:08.328+09:00 DEBUG 47605 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Releasing JDBC Connection [HikariProxyConnection@127618303 wrapping conn0: url=jdbc:h2:mem:bc33bbb6-f38a-47ac-b20c-43b1dfc55fec user=SA] after transaction
2025-01-20T22:15:08.328+09:00  INFO 47605 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션2 시작
2025-01-20T22:15:08.328+09:00 DEBUG 47605 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2025-01-20T22:15:08.328+09:00 DEBUG 47605 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Acquired Connection [HikariProxyConnection@1038320631 wrapping conn0: url=jdbc:h2:mem:bc33bbb6-f38a-47ac-b20c-43b1dfc55fec user=SA] for JDBC transaction
2025-01-20T22:15:08.328+09:00 DEBUG 47605 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Switching JDBC Connection [HikariProxyConnection@1038320631 wrapping conn0: url=jdbc:h2:mem:bc33bbb6-f38a-47ac-b20c-43b1dfc55fec user=SA] to manual commit
2025-01-20T22:15:08.328+09:00  INFO 47605 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 트랜잭션2 롤백
2025-01-20T22:15:08.328+09:00 DEBUG 47605 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Initiating transaction rollback
2025-01-20T22:15:08.328+09:00 DEBUG 47605 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Rolling back JDBC transaction on Connection [HikariProxyConnection@1038320631 wrapping conn0: url=jdbc:h2:mem:bc33bbb6-f38a-47ac-b20c-43b1dfc55fec user=SA]
2025-01-20T22:15:08.329+09:00 DEBUG 47605 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Releasing JDBC Connection [HikariProxyConnection@1038320631 wrapping conn0: url=jdbc:h2:mem:bc33bbb6-f38a-47ac-b20c-43b1dfc55fec user=SA] after transaction

로그결과를 그림으로 보면 트랜잭션1은 커밋되었지만, 트랜잭션2는 롤백됨

3️⃣ 스프링 트랜잭션 전파3 - 전파 기본

트랜잭션을 각각 사용하는 것이 아닌 트랜잭션이 이미 진행중인데, 추가로 트랜잭션을 수행하면 어떻게 될까?
이런 경우 어떻게 동작할지 결정하는 것을 트랜잭션 전파(propagation)라 한다.
참고로 스프링은 다양한 트랜잭션 전파 옵션을 제공

참고
지금부터 설명하는 내용은 트랜잭션 전파의 기본 옵션인 REQUIRED를 기준으로 설명
옵션에 대한 내용은 마지막에 설명

외부 트랜잭션이 수행중인데, 내부트랜잭션이 추가로 수행됨
- 외부 트랜잭션이 수행중이고, 아직 끝나지 않은 상태에서 내부 트랜잭션이 수행
- 외부 트랜잭션이라고 이름 붙인 것은 둘 중 상대적으로 밖에 있기 때문에 외부 트랜잭션이라 한다. (처음 시작된 트랜잭션이라고 생각하면 된다.)
- 내부 트랜잭션은 외부에 트랜잭션이 수행되고 도중에 호출되기 때문에 마치 내부에 있는 것 처럼 보여서 내부 트랜잭션이라 한다.

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

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

➡️그럼 왜 이렇게 논리 트랜잭션과 물리 트랜잭션을 나누어 설명하는 것일까?

트랜잭션이 사용중일 때 다른 트랜잭션이 내부에 사용되면 여러가지 복잡한 상황이 연출될 수 있다.

✅ 원칙

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

➡️ 모든 트랜잭션 매니저를 커밋해야 물리 트랜잭션이 커밋된다. 하나의 트랜잭션 매니저라 도 롤백하면 물리 트랜잭션은 롤백된다.

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

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

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

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

3️⃣ 스프링 트랜잭션 전파3 - 전파 기본

트랜잭션을 각각 사용하는 것이 아닌 트랜잭션이 이미 진행중인데, 추가로 트랜잭션을 수행하면 어떻게 될까?
이런 경우 어떻게 동작할지 결정하는 것을 트랜잭션 전파(propagation)라 한다.
참고로 스프링은 다양한 트랜잭션 전파 옵션을 제공

참고
지금부터 설명하는 내용은 트랜잭션 전파의 기본 옵션인 REQUIRED를 기준으로 설명
옵션에 대한 내용은 마지막에 설명

외부 트랜잭션이 수행중인데, 내부트랜잭션이 추가로 수행됨
- 외부 트랜잭션이 수행중이고, 아직 끝나지 않은 상태에서 내부 트랜잭션이 수행
- 외부 트랜잭션이라고 이름 붙인 것은 둘 중 상대적으로 밖에 있기 때문에 외부 트랜잭션이라 한다. (처음 시작된 트랜잭션이라고 생각하면 된다.)
- 내부 트랜잭션은 외부에 트랜잭션이 수행되고 도중에 호출되기 때문에 마치 내부에 있는 것 처럼 보여서 내부 트랜잭션이라 한다.

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

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

➡️그럼 왜 이렇게 논리 트랜잭션과 물리 트랜잭션을 나누어 설명하는 것일까?

트랜잭션이 사용중일 때 다른 트랜잭션이 내부에 사용되면 여러가지 복잡한 상황이 연출될 수 있다.

✅ 원칙

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

➡️ 모든 트랜잭션 매니저를 커밋해야 물리 트랜잭션이 커밋된다. 하나의 트랜잭션 매니저라 도 롤백하면 물리 트랜잭션은 롤백된다.

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

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

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

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

예제를 통해서 스프링 트랜잭션 전파 관련 이해해보자.

inner_commit() - BasicTxTest 추가

@Test
void inner_commit() {
		log.info("외부 트랜잭션 시작");
		TransactionStatus outer = txManager.getTransaction(new DefaultTransactionDefinition());
		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)이 된다.
내부 트랜잭션을 시작하는 시점에는 이미 외부 트랜잭션이 진행중인 상태이다. 이 경우 내부 트랜잭션은 외부트랜잭션에 참여한다.
트랜잭션 참여
- 내부 트랜잭션이 외부 트랜잭션에 참여한다는 뜻 → 내부 트랜잭션이 외부 트랜잭션을 그래도 이어 받아서 따른다는 뜻이다.
- 다른 관점으로 보면 외부 트랜잭션의 범위가 내부 트랜잭션까지 넓어진다는 뜻이다.
- 외부에서 시작된 물리적인 트랜잭션의 범위가 내부 트랜잭션까지 넓어진다는 뜻이다.
- 따라서 외부 트랜잭션과 내부 트랜잭션이 하나의 물리 트랜잭션으로 묶이는 것
내부 트랜잭션은 이미 진행중인 외부 트랜잭션에 참여한다. 이 경우 신규 트랜잭션이 아니다.( isNewTransaction=false).

➡️ 외부 트랜잭션과 내부 트랜잭션이 하나의 물리 트랜잭션으로 묶인다고 설명

하지만 코드를 잘 보면 커밋을 두번 호출했다.
트랜잭셕은 하나의 커넥션에 커밋은 한번만 호출할 수 있음. 커밋이나 롤백을 하면 해당 트랜잭션은 끝나버린다.

txManager.commit(inner);
txManager.commit(outer);

로그 실행결과

2025-01-20T23:23:28.271+09:00  INFO 47880 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 외부 트랜잭션 시작
2025-01-20T23:23:28.272+09:00 DEBUG 47880 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2025-01-20T23:23:28.273+09:00 DEBUG 47880 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Acquired Connection [HikariProxyConnection@444211664 wrapping conn0: url=jdbc:h2:mem:aa2ba39d-0ddb-4b64-b400-046e6f2d1130 user=SA] for JDBC transaction
2025-01-20T23:23:28.274+09:00 DEBUG 47880 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Switching JDBC Connection [HikariProxyConnection@444211664 wrapping conn0: url=jdbc:h2:mem:aa2ba39d-0ddb-4b64-b400-046e6f2d1130 user=SA] to manual commit
2025-01-20T23:23:28.275+09:00  INFO 47880 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : outer.isNewTransaction() = true

2025-01-20T23:23:28.275+09:00  INFO 47880 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 내부 트랜잭션 시작
2025-01-20T23:23:28.275+09:00 DEBUG 47880 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Participating in existing transaction
2025-01-20T23:23:28.275+09:00  INFO 47880 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : inner.isNewTransaction() = false
2025-01-20T23:23:28.275+09:00  INFO 47880 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 내부 트랜잭션 커밋

2025-01-20T23:23:28.275+09:00  INFO 47880 --- [    Test worker] hello.springtx.propagation.BasicTxTest   : 외부 트랜잭션 커밋
2025-01-20T23:23:28.275+09:00 DEBUG 47880 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Initiating transaction commit
2025-01-20T23:23:28.275+09:00 DEBUG 47880 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Committing JDBC transaction on Connection [HikariProxyConnection@444211664 wrapping conn0: url=jdbc:h2:mem:aa2ba39d-0ddb-4b64-b400-046e6f2d1130 user=SA]
2025-01-20T23:23:28.276+09:00 DEBUG 47880 --- [    Test worker] o.s.j.d.DataSourceTransactionManager     : Releasing JDBC Connection [HikariProxyConnection@444211664 wrapping conn0: url=jdbc:h2:mem:aa2ba39d-0ddb-4b64-b400-046e6f2d1130 user=SA] after transaction

내부 트랜잭션을 시작할 때 Participating in existing transaction이라는 메시지를 확인
- 이 메시지는 내부 트랜잭션이 기존에 존재하는 외부 트랜잭션에 참여한다는 뜻.
실행 결과를 보면 외부 트랜잭션을 시작하거나 커밋할 때는 DB 커넥션을 통한 물리 트랜잭션을 시작(manual commit)하고, DB 커넥션을 통해 커밋 하는 것을 확인할 수 있다. 하지만 내부 트랜잭션을 시작하거나 커밋할 때는 DB 커넥션을 통해 커밋하는 로그를 전혀 확인할 수 없다.
따라서 외부 트랜잭션만 물리 트랜잭션을 시작하고 커밋한다.
만약 내부 트랜잭션이 실제 물리 트랜잭션을 커밋하면 트랜잭션이 끝나버리기 때문에, 트랜잭션을 처음 시작한 외부 트랜잭션까지 이어갈 수 없다. 따라서 내부 트랜잭션은 DB 커넥션을 통한 물리 트랜잭션을 커밋하면 안된다.
스프링은 이렇게 여러 트랜잭션이 함께 사용되는 경우, 처음 트랜잭션을 시작한 외부 트랜잭션이 실제 물리 트랜잭션을 관리하도록 한다. 이를 통해 트랜잭션 중복 커밋 문제를 해결한다.

트랜잭션 전파가 실제 어떻게 동작하는지 그림으로 알아보자.

✅요청 흐름 외부 트랜잭션

txManager.getTransaction() 를 호출해서 외부 트랜잭션을 시작한다.
트랜잭션 매니저는 데이터소스를 통해 커넥션을 생성한다.
생성한 커넥션을 수동 커밋 모드(setAutoCommit(false) )로 설정한다. - 물리 트랜잭션 시작
트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관한다.
트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus에 담아서 반환하는데, 여기에 신규

트랜잭션의 여부가 담겨 있다. isNewTransaction를 통해 신규 트랜잭션 여부를 확인할 수 있다. 트랜

잭션을 처음 시작했으므로 신규 트랜잭션이다.(true)
로직1이 사용되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 트랜잭션이 적용된 커넥션을 획득

해서 사용한다.

✅요청 흐름 내부 트랜잭션

txManager.getTransaction() 를 호출해서 내부 트랜잭션을 시작한다.
트랜잭션 매니저는 트랜잭션 동기화 매니저를 통해서 기존 트랜잭션이 존재하는지 확인한다.
기존 트랜잭션이 존재하므로 기존 트랜잭션에 참여한다. 기존 트랜잭션에 참여한다는 뜻은 사실 아무것도

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

✅ 응답 흐름 내부 트랜잭션

로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋한다.
트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 이 경우 신규 트랜잭션이 아니

기 때문에 실제 커밋을 호출하지 않는다. 이 부분이 중요한데, 실제 커넥션에 커밋이나 롤백을 호출하면 물
리 트랜잭션이 끝나버린다. 아직 트랜잭션이 끝난 것이 아니기 때문에 실제 커밋을 호출하면 안된다. 물리
트랜잭션은 외부 트랜잭션을 종료할 때 까지 이어져야한다.

✅ 응답 흐름 외부 트랜잭션

로직1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋한다.
트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 외부 트랜잭션은 신규 트랜잭

션이다. 따라서 DB 커넥션에 실제 커밋을 호출한다.
트랜잭션 매니저에 커밋하는 것이 논리적인 커밋이라면, 실제 커넥션에 커밋하는 것을 물리 커밋이라 할 수

있다. 실제 데이터베이스에 커밋이 반영되고, 물리 트랜잭션도 끝난다.

✅ 핵심 정리

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

Navigation Menu

Uh oh!

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

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 1 comment

Select a reply

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

YuDeokRin Jan 20, 2025 Maintainer

스프링 트랜잭션 전파1 - 기본

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

2️⃣ 스프링 트랜잭션 전파2 - 트랜잭션 두 번 사용

➡️ 트랜잭션1

➡️ 트랜잭션2

⚠️주의!

3️⃣ 스프링 트랜잭션 전파3 - 전파 기본

✅ 원칙

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

3️⃣ 스프링 트랜잭션 전파3 - 전파 기본

✅ 원칙

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

✅요청 흐름 외부 트랜잭션

✅요청 흐름 내부 트랜잭션

✅ 응답 흐름 내부 트랜잭션

✅ 응답 흐름 외부 트랜잭션

✅ 핵심 정리

Replies: 1 comment

YuDeokRin
Jan 20, 2025
Maintainer