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

[6om1n]

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

• BasicTxTest

package hello.springtx;


import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.context.TestConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.jdbc.datasource.DataSourceTransactionManager;
import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.TransactionStatus;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.interceptor.DefaultTransactionAttribute;

import javax.sql.DataSource;

@Slf4j
@SpringBootTest
public class BasicTxTest {
    
    @Autowired
    PlatformTransactionManager txMananger;
    
    @TestConfiguration
    static class Config{ 
        @Bean
        public PlatformTransactionManager transactionManager(DataSource dataSource){
            return new DataSourceTransactionManager(dataSource);
        }
    }
    
    @Test
    void commit() {
        log.info("트랜잭션 시작");
        TransactionStatus status = txMananger.getTransaction(new DefaultTransactionAttribute());
        log.info("트랜잭션 커밋 시작");
        txMananger.commit(status);
        log.info("트랜잭션 커밋 완료");
    }
    
    @Test
    void rollback() {
        log.info("트랜잭션 시작");
        TransactionStatus status = txMananger.getTransaction(new DefaultTransactionAttribute());
        log.info("트랜잭션 롤백 시작");
        txMananger.rollback(status);
        log.info("트랜잭션 롤백 완료");
    }
}

• @TestConfiguration : 해당 테스트에서 필요한 스프링 설정을 추가로 할 수 있다.
• DataSourceTransactionManager 를 스프링 빈으로 등록했다. 이후 트랜잭션 매니저인 PlatformTransactionManager 를 주입 받으면 방금 등록한 DataSourceTransactionManager 가 주입된다.

실행하기 전에 트랜잭션 관련 로그를 확인할 수 있도록 다음 추가

logging.level.org.springframework.transaction.interceptor=TRACE
 logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManager=D
 EBUG
 #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

commit()

txManager.getTransaction(new DefaultTransactionAttribute()) 트랜잭션 매니저를 통해 트랜잭션을 시작한다.

txManager.commit(status) : 트랜잭션을 커밋한다.

• commit() - 실행 로그
  

• rollback()
  txManager.getTransaction(new DefaultTransactionAttribute()) : 트랜잭션 매니저를 통해 트랜잭션을 시작한다.

txManager.rollback(status) : 트랜잭션을 롤백한다.

• rollback() - 실행 로그
  

---

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

트랜잭션이 각각 따로 사용되는 경우를 확인해보자.
이 예제는 트랜잭션1 이 완전히 끝나고나서 트랜잭션2 를 수행한다.

• double_commit() - BasicTxTest 추가

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

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

• double_commit() 실행 로그
  

트랜잭션1

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

트랜잭션2

• Acquired Connection [HikariProxyConnection@ 778350106 wrapping conn0] for JDBC transaction
  • 트랜잭션2을 시작하고, 커넥션 풀에서 conn0 커넥션을 획득했다.
• Releasing JDBC Connection [HikariProxyConnection@ 778350106 wrapping conn0] 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]

히카리 커넥션 풀이 반환해주는 커넥션을 다루는 프록시 객체의 주소가 트랜잭션1은 HikariProxyConnection@1000000 이고, 트랜잭션2 는 HikariProxyConnection@2000000 으로 서로 다른 것을 확인할 수 있다.
결과적으로 conn0 을 통해 커넥션이 재사용 된 것을 확인할 수 있고, HikariProxyConnection@1000000 , HikariProxyConnection@2000000 를 통해 각각 커넥션 풀에서 커넥션을 조회한 것을 확인할 수 있다.

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

• 이 경우 트랜잭션을 각자 관리하기 때문에 전체 트랜잭션을 묶을 수 없다. 예를 들어 트랜잭션1 이 커밋하고 트랜잭션2가 롤백하는 경우 트랜잭션1 에서 저장한 데이터는 커밋되고, 트랜잭션2에서 저장한 데이터는 롤백된다.

• double_commit_rollback() - BasicTxTest 추가

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

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

• 예제에서는 트랜잭션1은 커밋하고, 트랜잭션2는 롤백한다.

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

• double_commit_rollback() 실행 로그

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

• 로그를 보면 트랜잭션1이 커밋되지만, 트랜잭션2는 롤백되는 것을 확인할 수 있다.

---

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

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

내용은 트랜잭션 전파의 기본 옵션인 REQUIRED 를 기준으로 설명한다.

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

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

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

• 스프링은 이해를 돕기 위해 논리 트랜잭션과 물리 트랜잭션이라는 개념을 나눈다.

• 논리 트랜잭션들은 하나의 물리 트랜잭션으로 묶인다.

• 물리 트랜잭션은 우리가 이해하는 실제 데이터베이스에 적용되는 트랜잭션을 뜻한다. 실제 커넥션을 통해서 트랜잭션을 시작(setAutoCommit(false)) 하고, 실제 커넥션을 통해서 커밋, 롤백하는 단위이다.

• 논리 트랜잭션은 트랜잭션 매니저를 통해 트랜잭션을 사용하는 단위이다.

• 이러한 논리 트랜잭션 개념은 트랜잭션이 진행되는 중에 내부에 추가로 트랜잭션을 사용하는 경우에 나타난다. 단순히 트랜잭션이 하나인 경우 둘은 구분하지 않는다.

그럼 왜 이렇게 논리 트랜잭션과 물리 트랜잭션을 나누어 설명하는 것일까?
트랜잭션이 사용중일 때 또 다른 트랜잭션이 내부에 사용되면 여러가지 복잡한 상황이 발생한다. 이 때 논리 트랜잭션 개념을 도입하면 다음과 같은 단순한 원칙을 만들 수 있다.

원칙

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

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

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

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

---

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

• inner_commit() - BasicTxTest 추가

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

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

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

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

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

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

스프링은 어떻게 외부 트랜잭션과 내부 트랜잭션을 묶어서 하나의 물리 트랜잭션으로 묶어서 동작하게 하는지 자세히 알아보자.

• 실행 결과 - inner_commit()

 외부 트랜잭션 시작
**
 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 커넥션을 통해 커밋하는 로그를 전혀 확인할 수 없다.
• 정리하면 외부 트랜잭션만 물리 트랜잭션을 시작하고, 커밋한다.
• 만약 내부 트랜잭션이 실제 물리 트랜잭션을 커밋하면 트랜잭션이 끝나버리기 때문에, 트랜잭션을 처음 시작한 외부 트랜잭션까지 이어갈 수 없다. 따라서 내부 트랜잭션은 DB 커넥션을 통한 물리 트랜잭션을 커밋하면 안된다.
• 스프링은 이렇게 여러 트랜잭션이 함께 사용되는 경우, 처음 트랜잭션을 시작한 외부 트랜잭션이 실제 물리 트랜잭션을 관리 하도록 한다. 이를 통해 트랜잭션 중복 커밋 문제를 해결한다.

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

요청 흐름 - 외부 트랜잭션

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

요청 흐름 - 내부 트랜잭션

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

응답 흐름 - 내부 트랜잭션

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

응답 흐름 - 외부 트랜잭션

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

핵심 정리

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

---