기술스택
- JDK 17
- Spring Boot 3.3.5
먼저 들어가기 앞서 로그를 확인하기 위해 application.properties에 다음과 같은 코드를 추가를 하자.
logging.level.org.springframework.transaction.interceptor=TRACE
logging.level.org.springframework.jdbc.datasource.DataSourceTransactionManager=DEBUG
#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
1. 트랜잭션 커밋, 롤백
먼저 간단한 예제 코드로 스프링 트랜잭션을 실행해보겠다.
@Slf4j
@SpringBootTest
public class BasicTxTest {
@Autowired
PlatformTransactionManager txManager;
@TestConfiguration
static class Config{
@Bean
public PlatformTransactionManager transactionManager(DataSource dataSource){
return new DataSourceTransactionManager(dataSource);
}
}
@Test
void commit(){
log.info("트랜잭션 시작");
TransactionStatus status = txManager.getTransaction(new DefaultTransactionAttribute());
log.info("트랜잭션 커밋");
txManager.commit(status);
log.info("트랜잭션 커밋 종료");
}
@Test
void rollback(){
log.info("트랜잭션 시작");
TransactionStatus status = txManager.getTransaction(new DefaultTransactionAttribute());
log.info("트랜잭션 롤백 시작");
txManager.rollback(status);
log.info("트랜잭션 롤백 종료");
}
}
이미 다들 학습한 내용들이라서 이해하기 어렵지는 않을 것이다.
실행결과는 다음과 같은 사진으로 나온다.
2. 트랜잭션 두번 사용
이번에는 트랜잭션이 각각 따로 사용되는 경우를 확인해보자.
트랜잭션1이 완전히 끝나고 나서 트랜잭션 2를 수행한다. 이 코드는 위 코드 아래에 작성했다.
@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);
}
실행 결과는 다음과 같다.
HikariCP를 사용하기 때문에 두개의 트랜잭션 다 conn0을 사용하는 것을 확인할 수 있다.
트랜잭션1은 conn0 커넥션을 모두 사용하고 커넥션 풀에 반납까지 완료했다. 이후에 트랜잭션2가 conn0을 커넥션풀에서 획득한 것이다. 따라서 둘은 완전히 다른 커넥션으로 인지하는 것이 맞다.
두개의 트랜잭션 따로 동작하는 것도 볼 수 있다.
먼저 트랜잭션이 시작되는 코드가 있다면 트랜잭션 매니저가 커넥션풀에서 커넥션을 얻어온다. 그리고 AutoCommit을 false로 변경해준다.
그리고 얻어온 커넥션을 트랜잭션 동기화 매니저에 보관 후 비즈니스 로직을 호출한다. 이때 비즈니스 로직에서 데이터베이스를 접근할 때 트랜잭션 동기화 매니저에 보관되어 있는 커넥션을 사용해 접근한다.
따라서 이 코드에서는 이러한 싸이클을 두번 호출한다.
3. 트랜잭션 전파 기본
만약 트랜잭션을 각각 사용하는 것이 아니라 트랜잭션이 이미 진행중인데, 여기에 추가로 트랜잭션을 수행하면 어떻게 될까?
기존 트랜잭션과 별도로 진행할지, 아니면 같이 수행을 해야할지 동작을 결정하는 것을 트랜잭션 전파(propagation)이라 한다.
만약 트랜잭션이 수행중인데 그 안에서 또 추가로 트랜잭션이 수행되면 스프링에서 이 경우 두개의 트랜잭션을 하나의 트랜잭션으로 만들어준다.
외부 트랜잭션이라고 이름 붙인 것은 상대적으로 밖에 있기 때문에 외부 트랜잭션이라고 지었다. 쉽게 생각하면 처음 시작된 트랜잭션으로 이해하면 된다.
내부 트랜잭션은 외부 트랜잭션이 수행되고 있는 도중에 호출되기 때문에 마치 내부에 있는 것 처럼 보여서 내부 트랜잭션이라고 지었다.
스프링은 물리 트랜잭션, 논리 트랜잭션이라는 개념으로 나눈다. 논리 트랜잭션들은 하나의 물리 트랜잭션으로 묶인다.
물리 트랜잭션은 실제 커넥션을 통해서 트랜잭션 시작하고, 실제 커넥션을 통해서 커밋, 롤백하는 단위이다.
논리 트랜잭션은 트랜잭션을 사용하는 단위이다.
이러한 논리 트랜잭션 개념은 트랜잭션이 진행되는 중에 내부에 추가로 트랜잭션을 사용하는 경우에만 나타난다. 단순히 하나의 트랜잭션인 경우 둘을 구분하지 않는다.
이러한 물리, 논리 트랜잭션에 두가지 원칙이 있다.
- 모든 논리 트랜잭션이 커밋되어야 물리 트랜잭션이 커밋된다.
- 하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션은 롤백된다.
쉽게 설명하면 논리 트랜잭션이 모두 성공해야 커밋이 되고, 하나라도 롤백이 되면 전체 롤백이 된다는 말이다.
전파 예제
예제 코드를 통해서 스프링 트랜잭션 전파를 알아보겠다.
@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);
}
간략하게 코드를 설명하자면
- 외부 트랜잭션이 수행중인데, 내부 트랜잭션을 추가 수행
- 외부 트랜잭션은 처음 수행된 트랜잭션 이므로 outer.isNewTransaction = True가 된다.
- 내부 트랜잭션은 외부 트랜잭션이 수행중이므로 외부 트랜잭션에 참여한다.
이 예제에서는 외부 트랜잭션과 내부 트랜잭션이 하나의 물리 트랜잭션으로 묶인다고 설명했다. 그런데 코드를 잘보면 커밋을 두번 호출 했다. 트랜잭션을 생각해보면 하나의 커넥션에 커밋은 한번만 호출할 수 있다.
그런데 어떻게 하나의 물리 트랜잭션으로 묶여서 동작하게 되는지 알아보자.
실행결과는 다음과 같다.
내부 트랜잭션을 시작할 때 'Participating in existing transaction' 이라는 메시지를 확인할 수 있다. 이 메시지는 내부 트랜잭션이 기존에 존재하는 외부 트랜잭션에 참여한다는 뜻이다.
실행 결과를 보면 내부 트랜잭션을 시작하거나 커밋했다는 로그를 볼 수 없다.
정리하자면 외부 트랜잭션만 물리 트랜잭션을 시작하고, 커밋한다.
4. 트랜잭션 내부 롤백
만약 내부 트랜잭션은 롤백되는데 외부 트랜잭션이 커밋이 된다면 어떻게 될까?
@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); // rollback - only 표시
log.info("외부 트랜잭션 롤백");
txManager.commit(outer);
}
실행결과는 아래와 같다.
내부 트랜잭션이 롤백될 때 'marking existing transaction as rollback-only' 이라는 로그를 볼 수 있다. rollback -only를 마크를 남긴다는 말이다.
- 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백한다.
- 트랜재션 매니저는 롤백시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 신규 트랜잭션이 아니기 때문에 실제 롤백을 호출하지 않는다. 실제 커넥션에 커밋이나 롤백을 호출하면 물리 트랜잭션이 끝나기 때문이다.
- 내부 트랜잭션은 물리 트랜잭션을 롤백하지 않는 대신에 트랜잭션 동기화 매니저에 rollbackOnly=true라는 것을 마크해둔다.
- 로직1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋한다.
- 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작한다. 외부 트랜잭션은 신규 트랜잭션이다. 따라서 실제 커밋을 호출해야한다. 이때 먼저 트랜잭션 동기화 매니저에 rollbackOnly=true가 되어 있으면 롤백을 한다.
- 스프링은 이 경우 UnexpectedRollbackException 런타임 예외를 던진다. 그래서 롤백이 발생했다는 것을 명확히 알려준다.
5. REQUIRES_NEW
이번에는 외부 트랜잭션과 내부 트랜잭션을 완전히 분리해서 사용하는 방법에 대해 알아보자.
외,내부 트랜잭션을 완전히 분리해서 각각 별도의 물리 트랜잭션을 사용하는 방법이다. 그래서 커밋과 롤백도 각각 별도로 이루어지게 된다.
@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()); // true
log.info("내부 트랜잭션 롤백");
txManager.rollback(inner);
log.info("외부 트랜잭션 커밋");
txManager.commit(outer);
}
내부 트랜잭션을 시작할 때 전파 옵션인 propagationBehavior에 PROPAGATION_REQUIRES_NEW 옵션을 주었다.
이 전파 옵션을 사용하면 내부 트랜잭션을 시작할 때 기존 트랜잭션에 참여하는 것이 아니라 새로운 물리 트랜잭션을 만들어서 시작하게 된다.
6. 다양한 전파 옵션
- REQUIRED (기본값)
- 설명: 가장 많이 사용하는 기본 설정. 트랜잭션이 필수라는 의미로, 기존 트랜잭션이 없으면 새로운 트랜잭션을 생성하고, 있으면 기존 트랜잭션에 참여한다.
- 동작
- 기존 트랜잭션 없음: 새로운 트랜잭션을 생성한다.
- 기존 트랜잭션 있음: 기존 트랜잭션에 참여한다.
- REQUIRES_NEW
- 설명: 항상 새로운 트랜잭션을 생성한다. 기존 트랜잭션이 있으면 이를 일시 중지하고 새로운 트랜잭션을 시작한다.
- 동작
- 기존 트랜잭션 없음: 새로운 트랜잭션을 생성한다.
- 기존 트랜잭션 있음: 새로운 트랜잭션을 생성한다.
- SUPPORTS
- 설명: 트랜잭션을 지원한다는 뜻으로, 기존 트랜잭션이 있으면 그 안에서 실행되고 없으면 트랜잭션 없이 실행된다.
- 동작
- 기존 트랜잭션 없음: 트랜잭션 없이 진행한다.
- 기존 트랜잭션 있음: 기존 트랜잭션에 참여한다.
- NOT_SUPPORTED
- 설명: 트랜잭션을 지원하지 않는다는 의미. 기존 트랜잭션이 있으면 이를 일시 중지하고 트랜잭션 없이 메서드를 실행한다.
- 동작
- 기존 트랜잭션 없음: 트랜잭션 없이 진행한다.
- 기존 트랜잭션 있음: 트랜잭션 없이 진행한다. (기존 트랜잭션은 일시 중지된다)
- MANDATORY
- 설명: 트랜잭션이 반드시 있어야 하는 의무 사항이다. 기존 트랜잭션이 없으면 예외가 발생한다.
- 동작
- 기존 트랜잭션 없음: IllegalTransactionStateException 예외가 발생한다.
- 기존 트랜잭션 있음: 기존 트랜잭션에 참여한다.
- NEVER
- 설명: 트랜잭션을 사용하지 않는다는 의미로, 기존 트랜잭션이 있으면 예외가 발생한다. 트랜잭션 없이만 실행되기를 원할 때 사용한다.
- 동작
- 기존 트랜잭션 없음: 트랜잭션 없이 진행한다.
- 기존 트랜잭션 있음: IllegalTransactionStateException 예외가 발생한다.
- NESTED
- 설명: 기존 트랜잭션이 있으면 중첩 트랜잭션을 만들고, 없으면 새로운 트랜잭션을 생성한다. 중첩 트랜잭션은 외부 트랜잭션의 영향을 받지만, 중첩 트랜잭션의 롤백은 외부 트랜잭션에 영향을 주지 않는다.
- 동작
- 기존 트랜잭션 없음: 새로운 트랜잭션을 생성한다.
- 기존 트랜잭션 있음: 중첩 트랜잭션을 만든다.
- 참고 사항
- 부분 롤백 지원: 중첩 트랜잭션이 롤백되어도 외부 트랜잭션은 커밋될 수 있다.
- 종속성: 외부 트랜잭션이 롤백되면 중첩 트랜잭션도 함께 롤백된다.
- 기술적 요구사항: JDBC의 savepoint 기능을 사용하며, 데이터베이스 드라이버에서 해당 기능을 지원하는지 확인이 필요하다.
- 제한사항: 중첩 트랜잭션은 JPA에서는 사용할 수 없다.
정리
트랜잭션 전파에 대해, 트랜잭션 수행 중 그 안에서 또다른 트랜잭션이 수행 될 때 스프링은 어떻게 처리를 해주는지 알아보았다.
다음에는 트랜잭션 전파에 대해 어떻게 쓰는지 어떻게 활용하는지 알아보겠다.
'Spring Transaction' 카테고리의 다른 글
스프링 트랜잭션 전파 - 2 (0) | 2024.11.14 |
---|---|
스프링 트랜잭션 이해 (0) | 2024.11.13 |