Home Spring DB - 스프링 트랜잭션 전파
Post
Cancel

Spring DB - 스프링 트랜잭션 전파

트랜잭션 전파(propagation)

트랜잭션을 각각 사용하는 것이 아닌 하나의 트랜잭션이 이미 진행중인 상황에서 또다른 트랜잭션이 수행될떄, 어떤식으로 동작할지 결졍하는 것을 트랜잭션 전파(propagation) 이라 함.

Alt text

  • 외부 트랜잭션이 수행중이고, 아직 끝나기 전 내부 트랜잭션이 수행
    • 먼저 실행된 트랜잭션이 상대적으로 밖에 있기 떄문에 외부 트랜잭션이라 함
    • 외부 트랜잭션이 실행되고 있는 도중 호출되기 떄문에 마치 내부에 있는것으로 보여 내부 트랜잭션이라 함
  • 이 경우 스프링에선 외부 트랜잭션과 내부 트랜잭션을 묶어서 하나의 트랜잭션을 만들어 줌
    • 내부 트랜잭션이 외부 트랜잭션에 참여
    • 위와 같은 방식이 기본동작이며 옵션을 통해 다른 동작방식으로 선탱할 수 있음

Alt text

  • 스프링에선 개념적으로 물리 트랜잭션, 논리 트랜잭션이라고 나눔
    • 물리 트랜잭션은 실제 데이터베이스에 적용되는 트랜잭션을 뜻함
      • 실제 커넥션을 통해 트랜잭션을 시작(setAutoCommit(false))하고, 실제 커넥션을 통해 커밋, 롤백하는 단위
    • 논리 트랜잭션은 트랜잭션 매니저를 통해 트랜잭션을 사용하는 단위
  • 논리 트랜잭션들은 하나의 물리 트랜잭션으로 묶임
    • 기본인 REQUIRED 전파옵션을 사용할 할시, 이러한 논리 트랜잭션 개념은 트랜잭션이 진행되는 중에 내부에 추가로 트랜잭션을 사용하는 경우에 나타남

이와 같이 물리 트랜잭션, 논리 트랜잭션으로 나누면 다음과 같은 단순한 원칙을 만들 수 있음

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

Alt text

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

Alt text

  • 외부 트랜잭션이 롤백되었으므로 내부 트랜잭션이 커밋되어도 물리 트랜잭션은 롤백
  • 반대로 내부 트랜잭션이 롤백, 외부 트랜잭션이 커밋되어도 물리 트랜잭션은 롤백

이러한 외부 트랜잭션과 내부 트랜잭션에 대하여 테스트 코드로 확인해 볼 수 있음

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@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)가 됨
  • 내부 트랜잭션을 시작하는 시점에는 이미 외부 트랜잭션이 진행중인 상태이며 이 경우 내부 트랜잭션은 외부 트랜잭견에 참여하는 형태가 됨
  • 트랜잭션 참여
    • 내부 트랜잭션이 외부 트랜잭션에 참여한다는 뜻은 내부 트랜잭션이 외부 트랜잭션을 그대로 이어 받아 따른다는 뜻
    • 다른 관점으로 보면 외부 트랜잭션의 범위가 내부 트랜잭션까지 넓어진다는 뜻
    • 외부에서 시작된 물리적인 트랜잭션의 범위가 내부 트랜잭션까지 넓어진다는 뜻
    • 즉, 외부 트랜잭션과 내부 트랜잭션이 하나의 물리 트랜잭션으로 묶여버리게 됨
  • 내부 트랜잭션은 이미 진행되고 있는 트랜잭션에 참여하므로 신규 트랜잭션이 아님(isNewTransaction=false)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 실행 결과
외부 트랜잭션 시작
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 커넥션을 통한 물리 트랜잭션을 커밋하면 안됨
  • 스프링은 이렇게 여러 트랜잭션이 함꼐 사용되는 경우, 처음 트랜잭션을 시작한 외부 트랜잭션이 실제 물리 트랜잭션을 관리하도록 함. 이를 통해 트랜잭션 중복 커밋 문제를 해결 함

트랜잭션 전파의 동작 흐름

Alt text 요청 흐름 - 외부 트랜잭션 1.. txManager.getTransaction()을 호출하여 외부 트랙잭션을 시작

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

요청 흐름 - 내부 트랜잭션

  1. txManager.getTransaction() 를 호출해서 내부 트랜잭션을 시작
  2. 트랜잭션 매니저는 트랜잭션 동기화 매니저를 통해서 기존 트랜잭션이 존재하는지 확인
  3. 기존 트랜잭션이 존재하므로 기존 트랜잭션에 참여 함
      * 기존 트랜잭션에 참여한다는 뜻은 사실 아무것도 하지 않는다는 뜻
      * 이미 기존 트랜잭션인 외부 트랜잭션에서 물리 트랜잭션을 시작하였고 물리 트랜잭션이 시작된 커넥션을 트랜잭션 동기화 매니저에 담아두어 둔 상태
      * 이후 로직은 자연스럽게 트랜잭션 동기화 매니저에 보관된 기존 커넥션을 사용하게 됨 \
  4. 트랜잭션 매니저는 기존 생성되었던 트랜잭션을 찾아서 반환
      * 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus 에 담아서 반환하는데, 여기에서 isNewTransaction 를 통해 신규 트랜잭션 여부를 확인할 수 있음. 여기서는 기존 트랜잭션에 참여했기 때문에 신규 트랜잭션이 아님(false) \
  5. 로직2가 수행되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 외부 트랜잭션이 보관한 커넥션을 획득해서 사용

Alt text 응답 흐름 - 내부 트랜잭션

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

응답 흐름 - 외부 트랜잭션

  1. 로직1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋
  2. 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 외부 트랜잭션은 신규 트랜잭션 이므로 DB 커넥션에 실제 커밋을 호출
  3. 트랜잭션 매니저에 커밋하는 것이 논리적인 커밋이라면, 실제 커넥션에 커밋하는 것을 물리 커밋이라 할 수 있음. 실제 데이터베이스에 커밋이 반영되고, 물리 트랜잭션도 끝난다
트랜잭션 전파의 동작 흐름 정리
  • 주요 핵심은 트랜잭션 매니저에 커밋을 호출한다고 해서 항상 실제 커넥션에 물리 커밋이 발생하지 않는다는 것
  • 신규 트랜잭션인 경우에만 실제 커넥션을 사용하여 물리 커밋과 롤백을 수행함. 신규 트랜잭션이 아니면 실제 물리 커밋을 수행하지 않음
  • 트랜잭션이 내부에서 추가로 사용되면 트랜잭션 매니저에 커밋하는 것이 항상 물리 커밋으로 이어지지 않음. 그러므로 이러한 경우 논리 트랜잭션과 물리 트랜잭션으로 나뉘어 지게 됨. 또는 외부 트랜잭션과 내부 트랜잭션으로 나누어 설명하기도 함
  • 트랜잭션이 내부에서 추가로 사용되면 트랜잭션 매니저를 통해 논리 트랜잭션을 관리하고 모든 논리 트랜잭션이 커밋되면 물리 트랜잭션이 커밋 됨

외부 롤백시 흐름

Alt text 내부 트랜잭션은 커밋이 되는데 외부에서 트랜잭션이 롤백이 된다면, 내부 트랜잭션안 에서 저장한 데이터도 모두 함께 롤백 됨

Alt text 응답 흐름 - 내부 트랜잭션 1, 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋 \

  1. 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작 함. 이 경우 신규 트랜잭션이 아니기 때문에 실제 커밋을 호출하지 않음.
      * 실제 커넥션에 커밋이나 롤백을 호출하면 물리 트랜잭션이 끝나버리기 때문에 아직 트랜잭션이 끝난 것이 아닌 이 시점에는 실제 커밋을 호출하면 안됨.
      * 물리 트랜잭션은 외부 트랜잭션을 종료할 때 까지 이어져야 함 \

응답 흐름 - 외부 트랜잭션

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

내부 롤백시 흐름

Alt text 외부 롤백시의 흐름과 다르게 내부 트랜잭션은 롤백되고 외부 트랜잭션이 커밋되는 상황이라면 단순히 해결되지 않는 문제가 발생함.

이에 대하여 응답 흐름을 확인해보면 아래와 같음

Alt text 응답 흐름 - 내부 트랜잭션 1, 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백

  1. 트랜잭션 매니저는 롤백 시점에 신규 트랜잭션 여부에 따라 다르게 동작함. 이 경우 신규 트랜잭션이 아니기 때문에 실제 롤백을 호출하지 않음
      * 실제 커넥션에 커밋이나 롤백을 호출하면 물리 트랜잭션이 끝나버리기 때문에 아직 트랜잭션이 끝난 것이 아닌 이 시점에는 실제 커밋을 호출하면 안됨.
      * 물리 트랜잭션은 외부 트랜잭션을 종료할 때 까지 이어져야 함 \
  2. 내부 트랜잭션은 물리 트랜잭션을 롤백하지 않는 대신에 트랜잭션 동기화 매니저에 rollbackOnly=true 라는 표시를 해둠 \

응답 흐름 - 외부 트랜잭션

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

트랜잭션 전파 흐름 정리

  • 논리 트랜잭션이 하나라도 롤백이 되면 물리 트랜잭션 또한 롤백을 진행함
  • 내부 논리 트랜잭션이 롤백되면 롤백 전용 마크를 표시함
  • 외부 트랜잭션을 커밋 할 떄 롤백 전용 마크를 확인하고, 롤백 전용 마크가 표시되어 있다면 물리 트랜잭션을 롤백한뒤, 만일 외부 트랜잭션이 롤백이 아닌 커밋을 한다면 UnexpectedRollbackException 예외를 던짐

REQUIRES_NEW

외부 트랜잭션과 내부 트랜잭션을 완전히 분리해서 사용하는 방법도 있음 이 방법은 내부 트랜잭션에 문제가 발생해도 외부 트랜잭션에는 영향을 주지 않음. 반대로 외부 트랜잭션에 문제가 발생해도 내부 트랜잭션에 영향을 주지 않음

Alt text

  • 이렇게 물리 트랜잭션을 분리하기 위해 내부 트랜잭션을 시작할때 REQUIRES_NEW 옵션을 사용
  • 외부 트랜잭션과 내부 트랜잭션이 각각 별도의 물리 트랜잭션을 가짐
    • DB 커넥션을 각각 따로 사용함
  • 내부 트랜잭션이 롤백되더라도 외부 트랜잭션에서 수행한 데이터에는 영향을 주지 않음
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
@Test
void inner_rollback_requires_new() {
    log.info("외부 트랜잭션 시작");
    TransactionStatus outer = txManager.getTransaction(new DefaultTransactionAttribute());
    log.info("outer.isNewTransaction()={}", outer.isNewTransaction());

    log.info("내부 트랜잭션 시작");
    // 별도의 DefaultTransactionAttribute 객체를 만들고
    // setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW)
    // 을 통해 물리 트랜잭션을 분리
    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); //커밋
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
외부 트랜잭션 시작
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
outer.isNewTransaction()=true

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

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

외부 트랜잭션 커밋
Initiating transaction commit
Committing JDBC transaction on Connection [HikariProxyConnection@1064414847 
wrapping conn0]
Releasing JDBC Connection [HikariProxyConnection@1064414847 wrapping conn0] 
after transaction
  • 외부 트랜잭션 시작
    • 외부 트랜잭션을 시작하면서 커넥션를 획득하고 manual commit 으로 변경하여 물리 트랜잭션을 시작
    • 외부 트랜잭션은 신규 트랜잭션임
  • 내부 트랜잭션 시작
    • 내부 트랜잭션을 시작하면서 커넥션를 획득하고 manual commit 으로 변경하여 물리 트랜잭션을 시작
    • 내부 트랜잭션은 외부 트랜잭션에 참여하는것이 아닌 PROPAGATION_REQUIRES_NEW 옵션을 사용했기 때문에 완전히 새로운 트랜잭션으로 생성됨
  • 내부 트랜잭션 롤백
    • 내부 트랜잭션을 롤백
    • 내부 트랜잭션은 신규 트랜잭션이기 때문에 실제 물리 트랜잭션을 롤백
  • 외부 트랜잭션 커밋
    • 외부 트랜잭션을 커밋
    • 외부 트랜잭션은 신규 트랜잭션이기 때문에 실제 물리 트랜잭션을 커밋

REQUIRES_NEW 옵션 사용시, 트랜잭션 전파의 동작 흐름

Alt text 요청 흐름 - 외부 트랜잭션 1, txManager.getTransaction()을 호출하여 외부 트랙잭션을 시작

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

요청 흐름 - 내부 트랜잭션

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

Alt text 응답 흐름 - 내부 트랜잭션

  1. 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백
  2. 트랜잭션 매니저는 롤백 시점에 신규 트랜잭션 여부에 따라 다르게 동작 함. 현재 신규 트랜잭션이므로 롤백을 수행 함
  3. 내부 트랜젝션이 con2 물리 트랜잭션을 롤백 함
      * 트랜잭션이 종료되고, con2는 종료되거나 커넥션 풀에 반납 됨
      * 이후 con1의 보류가 끝나고, 다시 con1을 사용 함 \

응답 흐름 - 외부 트랜잭션

  1. 외부 트랜잭션에 커밋을 요청
  2. 외부 트랜잭션은 신규 트랜잭션 이므로 물리 트랜잭션에 커밋 진행
  3. 이떄 rollbackOnly 설정을 체크 함. 위 상황에는 rollbackOnly 설정이 없으므로 커밋 진행
  4. 본인이 만든 con1 커넥션을 통해 물리 트랜잭션을 커밋
      * 트랜잭션이 종료되고, con1는 종료되거나 커넥션 풀에 반납 됨 \


</br>

  • 정리
    • REQUIRES_NEW 옵션을 사용하면 물리 트랜잭션이 명확하게 분리 됨
    • REQUIRES_NEW 옵션을 사용하면 데이터베이스 커넥션이 동시에 다수(내부 트랜잭션의 수)가 사용된 다는 점을 주의

다양한 전파 옵션

스프링은 다양한 트랜잭션 전파 옵션을 제공 함. 전파 옵션에 대해 별도의 설정을 하지 않으면 기본으로 REQUIRED 가 사용됨. 실무에서는 대부분 REQUIRED 옵션을 사용하고 가끔 REQUIRED_NEW 가 사용되며 나머지는 잘 사용되지 않음

  • REQUIRED
    • 가장 많이 사용되는 기본 설정
    • 기존 트랜잭션이 없으면 생성하고 있으면 참여 함
    • 트랜잭션이 필수라는 의미
    • 기존 트랜잭션 없음 : 새로운 트랜잭션을 생성
    • 기존 트랜잭션 있음 : 기존 트랜잭션에 참여
  • REQUIRED_NEW
    • 할상 새로운 트랜잭션을 생성
    • 기존 트랜잭션 없음 : 새로운 트랜잭션을 생성
    • 기존 트랜잭션 있음 : 새로운 트랜잭션을 생성
  • SUPPORT
    • 트랜잭션을 지원한 다는 뜻이며 기존 트랜잭션이 없으면 없는대로 진행하고 있다면 참여 함
    • 기존 트랜잭션 없음 : 트랜잭션 없이 진행
    • 기존 트랜잭션 있음 : 기존 트랜잭션에 참여
  • NOT_SUPPORT
    • 트랜잭션을 지원하지 않는 다는 의미
    • 기존 트랜잭션 없음 : 트랜잭션 없이 진행
    • 기존 트랜잭션 있음 : 트랜잭션 없이 진행하며 기존 트랜잭션은 보류 함
  • MANDATORY
    • 의무사항으로, 트랜잭션이 반드시 있어야 하며 기존 트랜잭션이 없다면 예외 발생
    • 기존 트랜잭션 없음 : IllegalTransactionStateException 예외 발생
    • 기존 트랜잭션 있음 : 기존 트랜잭션에 참여
  • NEVER
    • 트랜잭션을 사용하지 않는다는 의미이며 기존 트랜잭셩이 있다면 예외가 발생
    • 기존 트랜잭션도 허용하지 않는 강한 부정의 의미
    • 기존 트랜잭션 없음 : 트랜잭션 없이 진행
    • 기존 트랜잭션 있음 : IllegalTransactionStateException 예외 발생
  • NESTED
    • 기존 트랜잭션 없음 : 새로운 트랜잭션을 생성
    • 기존 트랜잭션 있음 : 중첩 트랜잭션에 참여
      • 중첩 트랜잭션은 외부 트랜잭션의 영향을 받지만 중첩 트랜잭션은 외부에 영향을 주지 않음
      • 중첩 트랜잭션이 롤백 되어도 외부 트랜잭션은 커밋할 수 있음
      • 외부 트랜잭션이 롤백 되면 중첩 트랜잭션도 함께 롤백 됨
    • JDBC savepoint 기능을 하용하여 각 DB 드라이버별로 해당 기능을 지원하는지 확인이 필요
    • JPA 에선 중첩 트랜잭션을 사용할 수 없음

isolation, timeout, readOnly는 트랜잭션이 처음 시작될때만 적용 되며 트랜잭션에 참여하는 경우에는 적용되지 않음. 따라서 REQUIRED를 통한 트랜잭션 시작, REQUIRED_NEW를 통한 트랜잭션 시작 시점에만 적용 됨.


참고

  • 스프링 DB - 데이터 접근 활용 기술(김영한)
This post is licensed under CC BY 4.0 by the author.