[Spring DB 2편] 10. 스프링 트랜잭션 전파

HJ·2023년 2월 8일
0

Spring DB 2편

목록 보기
10/11
post-custom-banner

김영한 님의 스프링 DB 2편 - 데이터 접근 활용 기술 강의를 보고 작성한 내용입니다.
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-db-2/dashboard


1. 트랜잭션

1-1. 단일 트랜잭션

public class BasicTxTest {

    @Autowired
    PlatformTransactionManager txManager;

    @Test
    void txTest() {

        TransactionStatus status = txManager.getTransaction(new DefaultTransactionAttribute());
        txManager.commit(status);
        txManager.rollback(status);
    }

    @TestConfiguration
    static class Config{
        @Bean
        public PlatformTransactionManager transactionManager(DataSource dataSource) {
            return new DataSourceTransactionManager(dataSource);
        }
    }
}
  • @Bean을 통해 직접 트랜잭션 매니저로 DataSourceTransactionManager 를 등록

   ➜ 원래는 스프링부트가 자동으로 등록해줌

   ➜ 트랜잭션 매니저를 주입 받으면 DataSourceTransactionManager 가 주입된다

  • getTransaction() : 트랜잭션 매니저를 통해 트랜잭션 시작 ( 획득 )

  • 참고로 DataSource 는 직접 등록하지 않았기 때문에 Hikari 커넥션 풀을 사용


1-2. 트랜잭션 두 번 사용

@Test
void double_commit() {

    TransactionStatus tx1 = txManager.getTransaction(new DefaultTransactionAttribute());
    txManager.commit(tx1);

    TransactionStatus tx2 = txManager.getTransaction(new DefaultTransactionAttribute());
    txManager.commit(tx2);
}
#커넥션 획득 로그
Acquired Connection [HikariProxyConnection@1492742163 wrapping conn0 ...

Acquired Connection [HikariProxyConnection@1515420182 wrapping conn0 ...
  • 트랜잭션을 각각 사용하는 경우 한 트랜잭션이 conn0 를 획득하고 반납한 후에 다른 트랜잭션이 conn0 를 획득하고 반납한다

  • Hikari 커넥션 풀에서 커넥션을 획득하면 실제 커넥션을 그대로 반환하는 것이 아니라 내부 관리를 위해 Hikari 프록시 커넥션이라는 객체를 생성해서 반환한다

  • 위 커넥션 획득 로그를 보면 conn0 를 재사용하지만 커넥션을 반환해주는 프록시 객체의 주소가 다른 것을 확인할 수 있다

  • 그러므로 각 트랜잭션이 획득한 두 커넥션은 완전히 다른 커넥션으로 인지하는 것이 맞다




2. 트랜잭션 전파

2-1. 개념

  • 1번 처럼 트랜잭션을 각각 사용하는 것이 아니라 트랜잭션이 이미 진행 중인데 추가로 트랜잭션을 수행하는 경우, 기존 트랜잭션과 별도로 트랜잭션을 진행할 수도 있고, 기존 트랜잭션을 이어 받아서 수행할 수도 있다

  • 이런 경우에 어떻게 동작할지 결정하는 것을 트랜잭션 전파라고 한다

  • 스프링은 다양한 트랜잭션 전파 옵션을 제공하며 기본 옵션은 REQUIRED 이다


2-2. 설명

  • 한 트랜잭션이 수행 중이고 아직 끝나지 않았는데 다른 트랜잭션이 수행된다

  • 이 때, 진행 중이던 트랜잭션은 외부 트랜잭션, 나중에 시작된 트랜잭션이 내부 트랜잭션이다

  • 스프링 이 경우 외부 트랜잭션과 내부 트랜잭션을 묶어서 하나의 트랜잭션을 만들어준다

  • 이렇게 내부 트랜잭션이 외부 트랜잭션에 참여하는 것이 기본 동작이고, 옵션을 통해 다른 동작방식을 선택할 수 있다


2-3. 물리 트랜잭션, 논리 트랜잭션

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

  • 물리 트랜잭션은 실제 DB에 적용되는 트랜잭션을 의미하는데 트랜잭션을시작하고 커밋, 롤백하는 단위이다

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


  • 모든 논리 트랜잭션이 커밋되어야 물리 트랜잭션이 커밋된다

  • 하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션은 롤백된다

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


2-4. 참고

  • 논리 트랜잭션의 개념은 트랜잭션 진행 중에 추가로 트랜잭션을 사용하는 경우에 나타난다

  • 트랜잭션이 하나인 경우라면 물리 트랜잭션, 논리 트랜잭션을 구분하지 않는다

  • 정확하게 말하면 REQUIRED 전파 옵션을 사용하는 경우에 나타난다




3. 전파 예제

3-1. 코드 확인

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 가 출력

  • 내부 트랜잭션은 외부 트랜잭션에 참여하기 때문에 isNewTransaction=false 가 출력

  • 내부 트랜잭션이 외부 트랜잭션에 참여한다는 뜻은 내부 트랜잭션이 외부 트랜잭션을 그대로 이어 받아서 따른다는 뜻이다

  • 즉, 외부 트랜잭션과 내부 트랜잭션이 하나의 물리 트랜잭션으로 묶이는 것이다


3-2. 로그 확인

외부 트랜잭션 시작
...
Switching JDBC Connection [HikariProxyConnection@2104539672 wrapping conn0: ... to manual commit // 수동 커밋 모드
outer.isNewTransaction()=true

내부 트랜잭션 시작
Participating in existing transaction	// 트랜잭션 참여
inner.isNewTransaction()=false

내부 트랜잭션 커밋	  // 커밋 이후 아무 로그도 출력되지 않았다
외부 트랜잭션 커밋
Initiating transaction commit
Committing JDBC transaction on Connection [HikariProxyConnection@2104539672 wrapping conn0: ...
Releasing JDBC Connection [HikariProxyConnection@2104539672 wrapping conn0: ...
  • 외부 트랜잭션은 DB 커넥션을 통한 물리 트랜잭션을 시작하고, DB 커넥션을 통해 커밋

    • Switching ... to manual commit : 수동 커밋 모드 설정 ( 트랜잭션 시작 )
  • 내부 트랜잭션을 시작할 때는 DB 커넥션을 이용하지 않고 존재하는 트랜잭션에 참여한다

    • Participating in existing transaction : 내부 트랜잭션이 외부 트랜잭션에 참여
  • 내부 트랜잭션 커밋 이후 아무 로그도 출력되지 않고 외부 트랜잭션 커밋 로그가 출력

   ➜ txManager.commit(inner);에서 아무 일도 수행되지 않았다

   ➜ 하나의 커넥션에 커밋이나 롤백은 한 번 밖에 수행할 수 없기 때문

  • 즉, 외부 트랜잭션만 물리 트랜잭션을 시작하고 커밋한다

  • 스프링은 여러 트랜잭션이 함께 사용되는 경우, 처음 트랜잭션을 시작한 외부 트랜잭션이 실제 물리 트랜잭션을 관리하도록 하여 트랜잭션 중복 커밋 문제를 해결한다


3-3. 요청 흐름 확인하기

  1. txManager.getTransaction() 를 호출해서 외부 트랜잭션을 시작한다

  2. 트랜잭션 매니저는 데이터소스를 통해 커넥션을 생성한다

  3. 생성한 커넥션을 수동 커밋 모드로 설정한다 - 물리 트랜잭션 시작

  4. 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관한다

  5. 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus 에 담아서 반환한다

    • 여기에 신규 트랜잭션의 여부가 담겨 있고 isNewTransaction() 을 통해 확인 가능

    • 트랜잭션을 처음 시작했으므로 신규 트랜잭션이다

  6. 로직 1이 사용되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 트랜잭션이 적용된 커넥션을 획득해서 사용한다


  1. txManager.getTransaction() 를 호출해서 내부 트랜잭션을 시작한다

  2. 트랜잭션 매니저는 트랜잭션 동기화 매니저를 통해서 기존 트랜잭션이 존재하는지 확인

  3. 기존 트랜잭션이 존재하므로 기존 트랜잭션에 참여한다

    • 이미 기존 트랜잭션인 외부 트랜잭션에서 물리 트랜잭션을 시작했고 물리 트랜잭션이 시작된 커넥션을 트랜잭션 동기화 매니저에 담아두었다

    • 이후 로직은 트랜잭션 동기화 매니저에 보관된 기존 커넥션을 사용하게 된다

  4. 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus 에 담아서 반환하는데, 여기서는 기존 트랜잭션에 참여했기 때문에 신규 트랜잭션이 아니다

  5. 로직 2가 사용되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 외부 트랜잭션이 보관한 커넥션을 획득해서 사용한다


3-4. 응답 흐름 확인하기

  1. 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋한다

  2. 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다

    • 이 경우 신규 트랜잭션이 아니기 때문에 실제 커밋을 호출하지 않는다

    • 실제 커넥션에 커밋이나 롤백을 호출하면 물리 트랜잭션이 끝나버린다

    • 그러나 아직 트랜잭션이 끝난 것이 아니기 때문에 실제 커밋을 호출하면 안되고, 물리 트랜잭션이 외부 트랜잭션을 종료할 때 까지 이어지도록 해야한다


  1. 로직 1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋한다

  2. 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다

    • 외부 트랜잭션은 신규 트랜잭션이기 때문에 DB 커넥션에 실제 커밋을 호출한다
  3. 트랜잭션 매니저에 커밋하는 것이 논리적인 커밋이라면, 실제 커넥션에 커밋하는 것을 물리 커밋이라 할 수 있다. 실제 데이터베이스에 커밋이 반영되고, 물리 트랜잭션도 끝난다


3-5. 정리

  • 트랜잭션 매니저에 커밋을 호출한다고해서 항상 실제 커넥션에 물리 커밋이 발생하지는 않는다

  • 신규 트랜잭션인 경우에만 실제 커넥션을 사용해서 물리 커밋과 롤백을 수행한다

  • 신규 트랜잭션이 아니면 실제 물리 커넥션을 사용하지 않는다

  • 트랜잭션이 내부에서 추가로 사용되면, 트랜잭션 매니저를 통해 논리 트랜잭션을 관리하고, 모든 논리 트랜잭션이 커밋되면 물리 트랜잭션이 커밋된다




4. 외부 롤백

4-1. 코드 및 로그 확인

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);
}
외부 트랜잭션 시작
...
Switching JDBC Connection [HikariProxyConnection@20888781 wrapping conn0: ... to manual commit // 수동 커밋 모드

내부 트랜잭션 시작
Participating in existing transaction	// 트랜잭션 참여

내부 트랜잭션 커밋
외부 트랜잭션 롤백
Initiating transaction rollback
Rolling back JDBC transaction on Connection [HikariProxyConnection@20888781 wrapping conn0: ...
Releasing JDBC Connection [HikariProxyConnection@20888781 wrapping conn0: ...
  • 내부 트랜잭션은 커밋되고, 외부 트랜잭션은 롤백되는 상황

  • 내부 트랜잭션은 커밋해도 아무 일도 일어나지 않는다

    • 내부 트랜잭션 커밋 시 실제로 커밋해버리면 트랜잭션이 종료되기 때문
  • 외부 트랜잭션이 롤백되면 실제 롤백이 수행된다

  • 즉, 내부 커밋에 관계 없이 외부에서 롤백되면 전체 트랜잭션이 롤백된다

    • 외부 트랜잭션이 물리 트랜잭션을 시작하고 롤백한다

    • 내부 트랜잭션은 물리 트랜잭션에 직접적으로 관여하지 않는다


4-2. 응답 흐름 확인

  1. 로직 2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋한다

  2. 신규 트랜잭션이 아니기 때문에 실제 커밋을 호출하지 않는다


  1. 로직 1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 롤백한다

  2. 외부 트랜잭션은 신규 트랜잭션이기 때문에 DB 커넥션에 실제 롤백을 호출한다

  3. 트랜잭션 매니저에 롤백하는 것이 논리적인 롤백이라면, 실제 커넥션에 롤백하는 것을 물리 롤백이라 할 수 있다. 실제 데이터베이스에 롤백이 반영되고, 물리 트랜잭션도 끝난다




5. 내부 롤백

5-1. 코드 및 로그 확인

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

    log.info("외부 트랜잭션 커밋");
    Assertions.assertThatThrownBy(() -> txManager.commit(outer))
                .isInstanceOf(UnexpectedRollbackException.class);
}
외부 트랜잭션 시작
...
Switching JDBC Connection [HikariProxyConnection@1144148902 wrapping conn0: ... to manual commit // 수동 커밋 모드

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

내부 트랜잭션 롤백
Participating transaction failed - marking existing transaction as rollback-only    // rollback-only 마킹
Setting JDBC transaction [HikariProxyConnection@1144148902 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@1144148902 wrapping conn0: ... // 최종 롤백
Releasing JDBC Connection [HikariProxyConnection@1144148902 wrapping conn0: ...
  • 내부 트랜잭션은 롤백, 외부 트랜잭션은 커밋하는 상황

  • 내부 트랜잭션을 롤백하면 실제 물리 트랜잭션을 롤백하진 않지만 현재 참여 중인 기존 트랜잭션에 rollback-only 라고 마킹

  • 외부 트랜잭션은 커밋했지만 전체 트랜잭션이 롤백 전용으로 표시되어 있기 때문에 물리 트랜잭션을 롤백

  • 외부 트랜잭션 커밋 시, UnexpectedRollbackException 이 발생한 것을 확인할 수 있다


5-2. 응답 흐름 확인

  1. 로직 2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백한다

  2. 신규 트랜잭션이 아니기 때문에 실제 롤백을 호출하지 않는다

  3. 내부 트랜잭션은 물리 트랜잭션을 롤백하지 않는 대신 트랜잭션 동기화 매니저에 rollbackOnly=true 라는 표시를 한다


  1. 로직 1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋한다

  2. 외부 트랜잭션은 신규 트랜잭션이기 때문에 DB 커넥션에 실제 커밋을 호출해야 한다

    • 이때 먼저 트랜잭션 동기화 매니저에 rollbackOnly=true 표시가 있는지 확인한다

    • 롤백 전용 표시가 있으면 물리 트랜잭션을 커밋하는 것이 아니라 롤백한다

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

  4. 시스템 입장에서는 커밋을 호출했지만 롤백이 되었다는 것은 분명하게 알려주어야 한다

    • 스프링은 커밋을 시도했지만, 기대하지 않은 롤백이 발생했다는 것을 알려주기 위해 UnexpectedRollbackException 런타임 예외를 던진다

5-3. 정리

  • 논리 트랜잭션이 하나라도 롤백되면 물리 트랜잭션은 롤백된다

  • 내부 논리 트랜잭션이 롤백되면 롤백 전용 마크를 표시한다

  • 외부 트랜잭션을 커밋할 때 롤백 전용 마크를 확인한다

  • 롤백 전용 마크가 표시되어 있으면 물리 트랜잭션을 롤백하고, UnexpectedRollbackException 예외를 던진다




6. REQUIRES_NEW

6-1. 개념

  • 외부 트랜잭션과 내부 트랜잭션을 분리해서 각각 별도의 물리 트랜잭션을 사용하는 방법

  • 그렇기 때문에 커밋과 롤백도 각각 별도로 이루어진다

  • 즉, 외부 트랜잭션과 내부 트랜잭션이 서로 영향을 주지 않는다


6-2. 동작 흐름

  • 물리 트랜잭션을 분리하려면 내부 트랜잭션을 시작할 때 REQUIRES_NEW 옵션을 사용한다

  • 외부 트랜잭션과 내부 트랜잭션이 각각 별도의 물리 트랜잭션을 가진다

  • 별도의 물리 트랜잭션을 가진다는 뜻은 DB 커넥션을 따로 사용한다는 뜻이다

  • 이 경우 내부 트랜잭션이 롤백되면서 로직 2가 롤백되어도 로직 1에서 저장한 데이터에는 영향을 주지 않는다

  • 최종적으로 로직 2는 롤백되고, 로직 1은 커밋된다


6-3. 코드 확인하기

@Test
void inner_rollback_requires_new() {

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

    log.info("내부 트랜잭션 시작");
    DefaultTransactionAttribute definition = new DefaultTransactionAttribute();
    definition.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);
    TransactionStatus inner = txManager.getTransaction(definition);
    log.info("inner.isNewTransaction()={}", inner.isNewTransaction());

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

    log.info("외부 트랜잭션 커밋");
    txManager.commit(outer);
}
  • setPropagationBehavior() 으로 옵션을 설정한다

  • 기본 옵션은 PROPAGATION_REQUIRED이고 기존 트랜잭션에 참여하는 설정이다

  • PROPAGATION_REQUIRES_NEW 는 기존 트랜잭션이 있어도 새로운 트랜잭션을 생성한다


6-4. 로그 확인하기

외부 트랜잭션 시작
Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
Acquired Connection [HikariProxyConnection@1778902730 wrapping conn0: ...
Switching JDBC Connection [HikariProxyConnection@1778902730 wrapping conn0: ... to manual commit
outer.isNewTransaction()=true

내부 트랜잭션 시작
Suspending current transaction, creating new transaction with name [null]
Acquired Connection [HikariProxyConnection@1319386445 wrapping conn1: ...
Switching JDBC Connection [HikariProxyConnection@1319386445 wrapping conn1: ... to manual commit
inner.isNewTransaction()=true

내부 트랜잭션 롤백
Initiating transaction rollback
Rolling back JDBC transaction on Connection [HikariProxyConnection@1319386445 wrapping conn1: ...
Releasing JDBC Connection [HikariProxyConnection@1319386445 wrapping conn1: ...
Resuming suspended transaction after completion of inner transaction

외부 트랜잭션 커밋
Initiating transaction commit
Committing JDBC transaction on Connection [HikariProxyConnection@1778902730 wrapping conn0: ...
Releasing JDBC Connection [HikariProxyConnection@1778902730 wrapping conn0: ...
  • 내부 트랜잭션을 시작할 때 잠시 현재 트랜잭션을 미뤄두고 새로운 커넥션( conn1 ) 획득

    • Suspending current transaction : 현재( 외부 ) 트랜잭션 미뤄두기

    • 새로운 커넥션인 conn1 을 획득하고 수동 커밋 모드 설정

    • 새로운 트랜잭션을 생성한 것이기 때문에 isNewTransaction=false

  • 내부 트랜잭션을 롤백하면 실제 롤백이 일어나고 conn1 을 반납 및 외부 트랜잭션 재실행


6-5. 요청 흐름 확인하기

  1. txManager.getTransaction() 를 호출해서 외부 트랜잭션을 시작

  2. 트랜잭션 매니저는 데이터소스를 통해 커넥션을 생성한다

  3. 생성한 커넥션을 수동 커밋 모드로 설정한다 - 물리 트랜잭션 시작

  4. 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관한다

  5. 트랜잭션 매니저는 신규 트랜잭션의 생성한 결과를 반환한다 isNewTransaction = true

  6. 로직 1이 사용되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 트랜잭션이 적용된 커넥션을 획득해서 사용한다


  1. REQUIRES_NEW 옵션과 함께 txManager.getTransaction() 를 호출해 내부 트랜잭션 시작

    • 트랜잭션 매니저는 REQUIRES_NEW 옵션을 확인하고, 기존 트랜잭션에 참여하는 것이 아니라 새로운 트랜잭션을 시작한다
  2. 트랜잭션 매니저는 데이터소스를 통해 커넥션을 생성한다

  3. 생성한 커넥션을 수동 커밋 모드로 설정한다. - 물리 트랜잭션 시작

  4. 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관한다

    • 이때 con1 은 잠시 보류되고, 지금부터는 con2 가 사용된다

    • 내부 트랜잭션을 완료할 때 까지 con2 가 사용된다

  5. 트랜잭션 매니저는 신규 트랜잭션의 생성한 결과를 반환한다 isNewTransaction = true

  6. 로직 2가 사용되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저에 있는 con2 커넥션을 획득해서 사용한다


6-6. 응답 흐름 확인하기

  1. 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백한다

  2. 트랜잭션 매니저는 롤백 시점에 신규 트랜잭션 여부에 따라 다르게 동작하는데 현재 내부 트랜잭션은 신규 트랜잭션이기 때문에 실제 롤백을 호출한다

  3. 내부 트랜잭션이 con2 물리 트랜잭션을 롤백한다

    • 트랜잭션이 종료되고, con2 는 종료되거나, 커넥션 풀에 반납된다

    • 이후 con1 의 보류가 끝나고, 다시 con1 을 사용한다


  1. 외부 트랜잭션에 커밋을 요청한다

  2. 외부 트랜잭션은 신규 트랜잭션이기 때문에 물리 트랜잭션을 커밋한다

  3. 이때 rollbackOnly 설정을 체크하는데 rollbackOnly 설정이 없으므로 커밋한다

  4. 본인이 만든 con1 커넥션을 통해 물리 트랜잭션을 커밋한다

    • 트랜잭션이 종료되고, con1 은 종료되거나, 커넥션 풀에 반납된다



7. 전파 옵션

7-1. 정리

옵션설명기존 트랜잭션이 없는 경우기존 트랜잭션이 있는 경우
REQUIRED트랜잭션이 필수새로운 트랜잭션을 생성기존 트랜잭션에 참여
REQUIRES_NEW항상 새로운 트랜잭션을 생성새로운 트랜잭션을 생성새로운 트랜잭션을 생성
SUPPORT트랜잭션을 지원한다트랜잭션 없이 진행기존 트랜잭션에 참여
NOT_SUPPORT트랜잭션을 지원하지 않는다트랜잭션 없이 진행트랜잭션 없이 진행
( 기존 트랜잭션은 보류 )
MANDATORY의무사항이다
없으면 예외가 발생한다
IllegalTransactionStateException
예외 발생
기존 트랜잭션에 참여
NEVER트랜잭션을 사용하지 않는다
기존 트랜잭션도 허용 X
트랜잭션 없이 진행IllegalTransactionStateException
예외 발생
NESTED새로운 트랜잭션을 생성중첩 트랜잭션을 만든다

7-2. NESTED

  • 중첩 트랜잭션은 외부 트랜잭션의 영향을 받지만, 외부에 영향을 주지 않는다

  • 중첩 트랜잭션이 롤백 되어도 외부 트랜잭션은 커밋할 수 있다

  • 외부 트랜잭션이 롤백 되면 중첩 트랜잭션도 함께 롤백된다

  • JDBC savepoint 기능을 사용한다. DB 드라이버에서 해당 기능을 지원하는지 확인이 필요하다

  • 중첩 트랜잭션은 JPA에서는 사용할 수 없다


7-3. 트랜잭션 전파와 옵션

  • 트랜잭션 전파의 기본 값은 REQUIRED

    • @Transactional만 있으면 REQUIRED 가 적용된 것임
  • isolation , timeout , readOnly 는 트랜잭션이 처음 시작될 때만 적용된다

  • 트랜잭션에 참여하는 경우에는 적용되지 않는다

  • ex> REQUIREDREQUIRES_NEW 를 통한 트랜잭션 시작 시점에만 적용된다

post-custom-banner

0개의 댓글