Home 스프링 트랜잭션 전파 개념
Post
Cancel

스프링 트랜잭션 전파 개념

Posted Oct 20, 2023
By
41 min read

트랜잭션이 둘 이상 있을 때 스프링은 어떻게 동작할까?

예를 들어 트랜잭션을 사용 중인데 그 안에서 또 트랜잭션을 사용하게 된다면?

이렇게 트랜잭션이 여러 번 실행되는 경우 스프링이 어떻게 동작하는지, 그리고 트랜잭션 전파라는 기능에 대해 알아본다.

우선 기본적인 커밋과 롤백에서의 트랜잭션 작동 방식을 다시 복습해보자.

  • 커밋/롤백
    • 트랜잭션 시작(생성)
    • 커넥션 획득 (커넥션풀 - Hikari)
    • 커밋/롤백
    • 커밋이 완료되면 커넥션을 다시 커넥션풀에 돌려준다.

위와 같은 경우는 트랜잭션이 한 번 사용된 것이다. 두 번 사용된 경우라면?

트랜잭션 두 번 사용

1
2
3
4
5
6
7
8
9
10
11
12

@Test  
void double_commit() {  
	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.commit(tx2);  
}
  • txManager: PlatformTransactionManager (DataSourceTransactionManager) 이다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

트랜잭션1 시작
Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
Acquired Connection [HikariProxyConnection@1470153313 wrapping conn0: url=jdbc:h2:mem:f4fa3889-56da-4715-aaa6-ce196a1113f5 user=SA] for JDBC transaction
Switching JDBC Connection [HikariProxyConnection@1470153313 wrapping conn0: url=jdbc:h2:mem:f4fa3889-56da-4715-aaa6-ce196a1113f5 user=SA] to manual commit
트랜잭션1 커밋
Initiating transaction commit
Committing JDBC transaction on Connection [HikariProxyConnection@1470153313 wrapping conn0: url=jdbc:h2:mem:f4fa3889-56da-4715-aaa6-ce196a1113f5 user=SA]
Releasing JDBC Connection [HikariProxyConnection@1470153313 wrapping conn0: url=jdbc:h2:mem:f4fa3889-56da-4715-aaa6-ce196a1113f5 user=SA] after transaction

트랜잭션2 시작
Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
Acquired Connection [HikariProxyConnection@405881980 wrapping conn0: url=jdbc:h2:mem:f4fa3889-56da-4715-aaa6-ce196a1113f5 user=SA] for JDBC transaction
Switching JDBC Connection [HikariProxyConnection@405881980 wrapping conn0: url=jdbc:h2:mem:f4fa3889-56da-4715-aaa6-ce196a1113f5 user=SA] to manual commit
트랜잭션2 커밋
Initiating transaction commit
Committing JDBC transaction on Connection [HikariProxyConnection@405881980 wrapping conn0: url=jdbc:h2:mem:f4fa3889-56da-4715-aaa6-ce196a1113f5 user=SA]
Releasing JDBC Connection [HikariProxyConnection@405881980 wrapping conn0: url=jdbc:h2:mem:f4fa3889-56da-4715-aaa6-ce196a1113f5 user=SA] after transaction

테스트를 수행해보면 위와 같은 로그를 확인할 수 있다.

  • 트랜잭션1
    • 트랜잭션 1을 시작하고 커넥션 풀에서 conn0을 획득한다.
    • 커밋이 되면 커넥션 풀에 conn0을 다시 반납한다.
  • 트랜잭션2
    • 트랜잭션 2를 시작하고 커넥션 풀에서 conn0을 획득한다.
    • 커밋이 되면 커넥션 풀에 conn0을 다시 반납한다.

트랜잭션을 두 번 수행한다고 해서 크게 달라지는 것은 없다. 각각 트랜잭션을 시작하고, 커밋/롤백을 수행하고, 커넥션 반납한다.

이 때 트랜잭션 1과 2가 같은 conn0 커넥션을 사용한다고 해서 두 트랜잭션이 같은 커넥션을 사용한다고 착각하면 안된다.

트랜잭션1이 사용한 conn0은 이미 사용이 끝나고 커넥션 풀에 반납이 되었고, 이 후 트랜잭션2가 사용한 conn0은 반납된 conn0을 다시 획득해 사용하는 것이다. 따라서 획득한 하나의 커넥션을 공유했다고 보기보다는 서로 다른 커넥션을 사용했다고 보는 것이 옳다.

온전히 같은 커넥션 conn0인지 구분하는 방법은 커넥션 풀이 반환해주는 Acquired Connection [HikariProxyConnection@1470153313 이 부분의 프록시 객체 주소를 보면 된다. 서로 다르다.

즉 물리적으로는 같은 커넥션 conn0이 사용된 것은 맞지만, 각각의 커넥션 풀에서 커넥션을 새로 조회한 것이기 때문에 논리적으로는 같은 커넥션이 아닌 것이다.

트랜잭션이 각각 수행되면서 사용되는 DB 커넥션도 다르다는 것을 확인했다.

트랜잭션을 각자 관리하기 때문에 트랜잭션 1이 커밋하고, 트랜잭션 2가 롤백하는 경우 트랜잭션 1에서 저장한 데이터는 커밋이 되는 것이고, 2에서 저장한 데이터는 롤백 되는 것이다.

트랜잭션 전파

위 처럼 트랜잭션을 각각 사용하는 것이 아닌, 트랜잭션이 이미 진행중인데 여기에 추가로 트랜잭션을 수행하면 어떻게 작동할까?

즉, 트랜잭션 1이 커밋이나 롤백을 아직 하지 않았는데 다른 트랜잭션을 시작하려하면 어떻게 동작할까?

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

기존 트랜잭션과 별도의 트랜잭션을 진행할 수도 있고, 기존 트랜잭션을 이어 받아 트랜잭션을 수행할 수도 있다.

(우선 아래 설명할 내용은 트랜잭션 전파의 기본 옵션인 REQUIRED를 기준으로 설명한다.)

외부 트랜잭션과 내부 트랜잭션

  • 외부 트랜잭션: 처음 시작된 트랜잭션.
  • 내부 트랜잭션: 외부 트랜잭션이 수행되고 있는 도중 호출되는 트랜잭션.

외부 트랜잭션이 수행중이고, 아직 종료되지 않았는데 내부 트랜잭션이 수행되는 상황을 가정한다.

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

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

스프링은 이해를 돕기위해 물리 트랜잭션, 논리 트랜잭션으로 나눈다.

  • 논리 트랜잭션: 하나의 물리 트랜잭션으로 묶이는 트랜잭션
    • 위의 가정에서는 외부 트랜잭션, 내부 트랜잭션
  • 물리 트랜잭션: 실제 데이터베이스에 적용되는 트랜잭션을 뜻한다. 실제 커넥션을 통해 트랜잭션을 시작하고, 실제 커넥션을 통해 커밋/롤백한다.
    • 위의 가정에서 외부 트랜잭션과 내부 트랜잭션을 묶은 하나의 트랜잭션

스프링은 왜 이렇게 물리 트랜잭션과 논리 트랜잭션으로 개념을 나누었을까?

트랜잭션이 사용 중일 때 또 다른 트랜잭션이 내부에 사용되면 여러 복잡한 상황이 발생한다. 이럴 때 논리 트랜잭션 개념을 도입하면 아래와 같은 단순한 원칙을 만들 수 있다.

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

기본 REQUIRED 옵션에서는 논리 트랜잭션이 하나라도 롤백되면 물리 트랜잭션을 롤백해야 한다.

코드로 확인

둘 다 커밋하는 상황을 코드로 본다.

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면 신규 트랜잭션이다.

위 코드를 실행하면 아래와 같은 로그를 확인할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12

외부 트랜잭션 시작 
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
  • 외부 트랜잭션을 시작할 때는 기존에 트랜잭션을 각각 수행했을 때와 같이 트랜잭션을 시작하는 것을 볼 수 있다. isNewTransaction()도 true이다.
  • 반면 외부 트랜잭션 수행도중 실행된 내부 트랜잭션의 경우에는?
    • Participating in existing transaction 이라는 문구를 볼 수 있다.
    • 즉 기존 트랜잭션에 참여한다는 것이다.
    • outer, inner 트랜잭션이 합쳐져 하나의 물리 트랜잭션이 된 것을 볼 수 있다.
    • isNewTransaction()도 false인 것을 볼 수 있다.
  • 내부 트랜잭션을 커밋할 때는 Initiating commit, Committing JDBC ~ 문구가 나타나지 않는다.
    • 하나의 물리 트랜잭션에 있는 논리 트랜잭션이 모두 커밋되어야 커밋할 수 있는 것을 볼 수 있다.
    • 외부 트랜잭션이 커밋이 되고 나서야 실제 커밋이 수행됐다.
    • 즉, 각각 커밋을 할때는 논리 트랜잭션이 커밋이 되고 실제로는 아무 동작이 없는 것이고, 하나의 물리 트랜잭션에 있는 트랜잭션이 모두 커밋임을 확인했을 때 비로소 실제 데이터베이스와 연결된 커넥션을 가지고 커밋을 수행하는 것이다.
    • 만약 내부 트랜잭션이 커밋할 때 실제 물리 트랜잭션을 커밋한다면 트랜잭션이 종료되기 때문에 외부 트랜잭션을 이어갈 수 없다.
  • 둘 다 커밋이 완료된 이후 커넥션을 반납할 때 외부 트랜잭션이 획득했던 커넥션을 반납하는 것을 볼 수 있다.

스프링은 이렇게 여러 트랜잭션이 함께 사용되는 경우, 처음 트랜잭션을 시작한 외부 트랜잭션이 실제 물리 트랜잭션을 관리하도록 한다.

이를 통해 트랜잭션 중복 커밋 문제를 해결한다.

동작 흐름

논리 트랜잭션이 모두 커밋인 경우

  • 외부 트랜잭션
    • 외부 트랜잭션을 시작한다.
    • 트랜잭션 매니저는 데이터소스를 통해 커넥션을 생성한다.
    • 생성한 커넥션을 수동 커밋 모드로 설정한다. => 물리 트랜잭션의 시작
    • 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관한다.
    • 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus에 담아 반환한다. 여기에는 신규 트랜잭션인지 여부도 담겨있다.
  • 내부 트랜잭션
    • 내부 트랜잭션을 시작한다.
    • 트랜잭션 매니저는 트랜잭션 동기화 매니저를 통해 기존 트랜잭션이 존재하는 지 체크한다.
    • 기존 트랜잭션이 존재하므로 기존 트랜잭션에 참여한다.
      • 기존 트랜잭션에 참여한다는 것은 사실 새로운 커넥션을 만든다거나 등등을 하지 않고 아무것도 하지 않는다는 뜻이다.
      • 이미 물리 트랜잭션이 진행 중이므로 그냥 두면 기존에 시작된 트랜잭션을 자연스럽게 사용하게 된다.
      • 이후 로직은 자연스럽게 트랜잭션 동기화 매니저에 보관된 기존 커넥션을 사용하게 된다.
    • 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus에 담아 반환한다. 신규 트랜잭션이 아니라는 정보도 담긴다.

  • 응답: 내부 트랜잭션
    • 로직이 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋한다.
    • 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다.
      • 이 경우 신규 트랜잭션이 아니기 때문에 실제 커밋을 호출하지 않는다.
      • 실제 커밋을 호출하면 트랜잭션을 이어갈 수 없다.
  • 응답: 외부 트랜잭션
    • 로직이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋한다.
    • 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다.
      • 이 경우 신규 트랜잭션이기 때문에 DB 커넥션에 실제 커밋을 호출한다.
      • 트랜잭션 매니저에 커밋하는 것이 논리적 커밋이라면 실제 커넥션에 커밋하는 것을 물리 커밋이라고 할 수 있다. 외부 트랜잭션의 응답에서는 물리 커밋이 일어나는 것이다.
    • 실제 DB에 커밋이 반영되고 물리 트랜잭션이 종료된다.

논리 트랜잭션 중 외부 트랜잭션이 롤백된 경우

우선 논리 트랜잭션이 하나라도 롤백이면 물리 트랜잭션이 롤백된다는 사실은 알고 있다. 내부에서는 어떻게 동작할까?

우선 로그를 통해 확인해본다.

1
2
3
4
5
6
7
8
9
10
11

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

외부 트랜잭션이 물리 트랜잭션을 시작하고, 롤백한다. 내부 트랜잭션은 물리 트랜잭션에 관여하지 않는다.

즉 외부 트랜잭션에서 시작한 물리 트랜잭션의 범위가 내부 트랜잭션까지 사용되고, 외부 트랜잭션이 롤백 되면서 물리 트랜잭션이 롤백된다. 따라서 내부 트랜잭션의 내용까지 롤백되는 것이다.

트랜잭션이 시작하는 과정은 같으므로 응답만 본다.

  • 응답: 내부 트랜잭션
    • 로직이 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋한다.
    • 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다.
      • 신규 트랜잭션이 아니기 때문에 실제 커밋을 호출하지 않는다.
  • 응답: 외부 트랜잭션
    • 로직이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 롤백한다.
    • 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다.
      • 신규 트랜잭션이기 때문에 DB커넥션에 실제 롤백을 호출한다.

둘 다 커밋인 경우와 사실 같다. 외부 트랜잭션이 롤백일 때는 롤백을 호출할 당시 실제 물리 트랜잭션의 롤백을 수행하므로 전체가 롤백이 되는 것을 확인할 수 있다.

그러나 내부가 롤백인데 외부가 커밋이라면? 만약 위와 같이 동작한다면 내부 트랜잭션은 신규 트랜잭션이 아니기 때문에 실제 롤백을 호출하지 않고, 외부가 커밋일 때 물리 트랜잭션을 커밋하게 되므로 우리가 아는 대로 동작하지 않는 것이다.

내부가 롤백이고, 외부가 커밋인 경우의 동작방식을 보자.

논리 트랜잭션 중 내부 트랜잭션이 롤백된 경우 (외부 커밋)

내부가 롤백이고, 외부가 커밋인 경우의 동작방식을 보자. 우선 로그를 통해 확인해본다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

외부 트랜잭션 시작  
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@220038608wrapping conn0]  
Releasing JDBC Connection [HikariProxyConnection@220038608 wrapping conn0] after transaction
  • 외부 트랜잭션 시작
    • 물리 트랜잭션을 시작한다.
  • 내부 트랜잭션 시작
    • 기존 트랜잭션에 참여한다.
  • 내부 트랜잭션 롤백
    • Participating transaction failed - marking existing transaction as rollback-only
    • 실제 물리 트랜잭션에 참여 실패한다.
    • 대신 기존에 존재하는 트랜잭션은 rollback-only로 마킹된다.
  • 외부 트랜잭션 커밋
    • Global transaction is marked as rollback-only
    • 커밋을 호출했지만, 전체 트랜잭션이 롤백 전용으로 마킹되어 있다고 나타난다.
    • 따라서 물리 트랜잭션을 롤백하는 것을 볼 수 있다.

  • 응답: 내부 트랜잭션
    • 로직이 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백한다. (로직에 문제가 생겼다.)
    • 트랜잭션 매니저는 롤백 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다.
      • 신규 트랜잭션이 아니기 때문에 실제 롤백을 호출하지 않는다.
    • 내부 트랜잭션은 물리 트랜잭션을 롤백하지 않는 대신, 트랜잭션 동기화 매니저에 rollbackOnly=true 라는 표시를 해둔다.
  • 응답: 외부 트랜재션
    • 로직이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋한다.
    • 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여무에 따라 다르게 동작한다.
      • 신규 트랜잭션이기 때문에 실제 커밋을 호출한다.
      • 그런데 이 때 먼저 트랜잭션 동기화 매니저에 rollbackOnly=true인지 체크한다. 롤백 전용 표시가 있다면 물리 트랜잭션을 커밋하는 것이 아닌 롤백한다.
    • 실제 데이터베이스에 롤백이 반영되고 물리 트랜잭션이 끝난다.

그런데 트랜잭션 매니저에 커밋을 호출한 개발자 입장에서는 커밋을 기대한 것인데, 롤백이 되어버린 상황이다.

예를 들면 고객의 주문이 성공했다고 처리한 것인데, 실제로는 중간에 어떤 과정에 오류가 생겨 그 트랜잭션이 롤백이 되어 주문이 생성되지 않은 것이다.

이런 경우 시스템은 롤백이 되었다는 것을 명확히 알려주어야 한다. 스프링의 경우 ‘UnexpectedRollbackException’ 런타임 예외를 던져 알려준다.

참고

애플리케이션 개발에서 중요한 기본 원칙은 모호함을 제거하는 것이다. 개발은 명확해야 한다.

이렇게 커밋을 호출했는데, 내부에서 롤백이 발생한 경우 모호하게 두면 아주 심각한 문제가 발생한다.

이렇게 기대한 결과가 다른 경우 예외를 발생시켜서 명확하게 문제를 알려주는 것이 좋은 설계이다.

REQUIRES_NEW

기본 옵션인 REQUIRED의 동작 방식이 아닌, 외부 트랜잭션 진행 중 내부 트랜잭션을 시작했음에도 외부 트랜잭션과 내부 트랜잭션을 완전히 분리해서 사용하려면 어떻게 해야 할까?

전파 옵션을 REQUIRES_NEW로 해주면 된다.

외부 트랜잭션과 내부 트랜잭션을 완전히 분리해서 각각 별도의 물리 트랜잭션을 사용하는 방법이다. 그래서 커밋과 롤백도 각각 별도로 이루어지게 된다. 어떤 트랜잭션이 롤백되어도 영향을 끼치지 않는다.

  • 위와 같이 물리 트랜잭션을 분리하려면 내부 트랜잭션을 시작할 때, REQUIRES_NEW 옵션을 사용하면 된다.
  • 외부 트랜잭션과 내부 트랜잭션이 각각 별도의 물리 트랜잭션을 가진다.
    • 각각 별도의 DB 커넥션을 따로 사용하게 되는 것이다.
  • 이 경우 내부 트랜잭션이 롤백되면서 로직2가 롤백되어도 로직 1에서 저장한 데이터에는 영향을 주지 않는다.
    • 로직2는 롤백되고 로직1은 커밋된다.

코드로 확인

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

@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);  
}
  • definition.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW)
    • 위 옵션을 통해 전파 옵션을 부여할 수 있다.

아래의 로그를 통해 동작을 보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

외부 트랜잭션 시작  
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
  • 외부 트랜잭션 시작
    • 외부 트랜잭션을 시작하면서 conn0을 획득하고 manual commit으로 변경해 물리 트랜잭션을 시작한다.
    • 외부 트랜잭션은 신규 트랜잭션이다.
  • 내부 트랜잭션 시작
    • 내부 트랜잭션을 시작하면서 conn1을 획득하고 manual commit으로 변경해 물리 트랜잭션을 시작한다. (프록시 객체도 다르다.)
    • 내부 트랜잭션은 외부 트랜잭션에 참여하지 않고, 새로운 신규 트랜잭션으로 생성된 것이다.
  • 내부 트랜잭션 롤백
    • 내부 트랜잭션을 롤백한다.
    • 신규 트랜잭션이기 때문에 실제 물리 트랜잭션을 롤백한다.
    • 내부 트랜잭션은 conn1을 사용해 외부의 커넥션과 다르므로 conn1에 물리 롤백을 수행해 분리될 수 있다.
  • 외부 트랜잭션 커밋
    • 외부 트랜잭션을 커밋한다.
    • 신규 트랜잭션이기 때문에 실제 물리 트랜잭션을 커밋한다.
    • 외부 트랜잭션은 conn0을 사용하므로 conn0에 물리 커밋을 수행한다.

REQUIRES_NEW를 사용하면 물리 트랜잭션이 명확하게 분리되는 것을 볼 수 있다.

단, 보다시피 데이터베이스 커넥션이 동시에 2개가 사용된다는 점을 주의해 사용해야 한다.

한 번의 HTTP 요청에 커넥션을 2개 사용하게 됨으로써 커넥션 풀이 빠르게 고갈될 수 있다.

동작 흐름

  • 요청: 외부 트랜잭션
    • 외부 트랜잭션을 시작한다.
    • 트랜잭션 매니저는 데이터소스를 통해 커넥션을 생성한다.
    • 생성한 커넥션을 수동 커밋 모드로 설정한다. => 물리 트랜잭션 시작
    • 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관한다. (con1)
    • 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus에 담아 반환한다.
    • 로직이 사용되고 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 트랜잭션이 적용된 커넥션을 획득해 사용한다.
  • 요청: 내부 트랜잭션
    • 내부 트랜잭션을 시작한다. 단 REQUIRES_NEW 옵션이 붙어있다.
    • 트랜잭션 매니저는 REQUIRES_NEW 옵션을 확인하고 기존 트랜잭션에 참여하는 대신 새로운 트랜잭션을 시작한다.
    • 트랜잭션 매니저는 데이터소스를 통해 커넥션을 생성한다.
    • 생성한 커넥션을 수동 커밋 모드로 설정한다. => 물리 트랜잭션 시작
    • 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관한다.
      • 이 때 con1은 잠시 보류(지연)되고, 지금부터 con2이 사용된다.
      • 내부 트랜잭션을 완료할 때 까지 con2이 사용된다.
    • 트랜잭션 매니저는 트랜잭션을 생성한 결과를 TransactionStatus에 담아 반환한다.
    • 로직이 사용되고 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 con2 커넥션을 획득해 사용한다.

  • 응답: 내부 트랜잭션
    • 로직이 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백한다.
    • 트랜잭션 매니저는 롤백 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다.
      • 신규 트랜잭션이기 때문에 실제 롤백을 호출한다.
    • 내부 트랜잭션이 con2 물리 트랜잭션을 롤백한다.
      • 이 트랜잭션은 종료되고 con2는 종료되거나 커넥션 풀에 반납된다.
      • 이 후 con1의 보류(지연)가 끝나고 다시 con1을 사용한다.
  • 응답: 외부 트랜잭션
    • 외부 트랜잭션에 커밋을 요청한다.
    • 외부 트랜잭션은 신규 트랜잭션이기 때문에 물리 트랜잭션을 커밋한다.
    • 이때 rollbackOnly 설정을 체크한다. rollbackOnly 설정이 없으므로 커밋한다.
    • 본인이 만든 con1 커넥션을 통해 물리 트랜잭션을 커밋한다.
      • 트랜잭션이 종료되고, con1 은 종료되거나, 커넥션 풀에 반납된다.

다양한 전파 옵션

스프링은 다양한 트랜잭션 전파 옵션을 제공한다. 전파 옵션에 별도의 설정을 하지 않으면 REQUIRED 가 기본으로 사용된다.

참고로 실무에서는 대부분 REQUIRED 옵션을 사용한다. 그리고 아주 가끔 REQUIRES_NEW 을 사용하고, 나머지는 거의 사용하지 않는다.

나머지 옵션은 필요할 때 찾아 쓰자.

REQUIRED

가장 많이 사용하는 기본 설정이다. 기존 트랜잭션이 없으면 생성하고, 있으면 참여한다

REQUIRES_NEW

항상 새로운 트랜잭션을 생성한다. 기존 트랜잭션이 있어도 생성한다.

SUPPORT

트랜잭션을 지원한다는 뜻이다. 기존 트랜잭션이 없으면, 없는대로 진행(생성이 아닌 없는대로 진행)하고, 있으면 참여한다.

NOT_SUPPORT

트랜잭션을 지원하지 않는다는 뜻이다. 트랜잭션 없이 진행한다.

MANDATORY

트랜잭션이 반드시 있어야 한다는 뜻이다. 기존 트랜잭션이 없으면 예외가 발생한다.

  • 기존 트랜잭션 없음: IllegalTransactionStateException 발생
  • 기존 트랜잭션 있음: 기존 트랜잭션에 참여

NEVER

트랜잭션을 사용하지 않는다는 의미이다. 기존 트랜잭션이 있으면 예외가 발생한다. 기존 트랜잭션도 허용하지 않는 강한 부정의 의미로 이해하면 된다.

NESTED

  • 기존 트랜잭션 없음: 새로운 트랜잭션을 생성한다.
  • 기존 트랜잭션 있음: 중첩 트랜잭션을 만든다.
    • 중첩 트랜잭션은 외부 트랜잭션의 영향을 받지만, 중첩 트랜잭션은 외부에 영향을 주지 않는다
    • 중첩 트랜잭션이 롤백 되어도 외부 트랜잭션은 커밋할 수 있다.
    • 외부 트랜잭션이 롤백 되면 중첩 트랜잭션도 함께 롤백된다.

중첩 트랜잭션은 JPA에서는 사용이 불가능하다.

트랜잭션 전파와 옵션

isolation, timeout, readOnly 는 트랜잭션이 처음 시작될 때만 적용된다.

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

즉 REQUIRED는 위의 상황에서 보면 외부 트랜잭션이 시작될 때만 적용되는 것이고 내부 트랜잭션이 시작해 참여할 때는 적용되지 않는 것이다.

REQUIRES_NEW는 전부 적용될 것이다.

Spring, 데이터베이스 접근 기술
java Spring SpringBoot
This post is licensed under CC BY 4.0 by the author.
Recently Updated
Contents