본 포스팅은 [인프런] 스프링 DB 1편 - 데이터 접근 핵심 원리 강의를 바탕으로 공부하고 정리한 글입니다.
트랜잭션 커밋, 롤백
트랜잭션 전파에 대해 알아보기 이전에 간단한 트랜잭션 코드를 통해 트랜잭션이 어떻게 동작하는지 확인해보자.
@Slf4j
@SpringBootTest
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("트랜잭션 롤백 완료");
}
}- txManager.getTransaction(new DefaultTransactionAttribute() : 트랜잭션 매니저를 통해 트랜잭션을 시작(획득)한다.
- txManager.commit(status) : 트랜잭션을 커밋한다.
- txManager.rollback(status) : 트랜잭션을 롤백한다.
만약 트랜잭션이 둘 이상 있다면 어떻게 동작할까?
@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("트랜잭션1 커밋");
txManager.commit(tx2);
}
출력된 로그를 보면, 트랜잭션1이 완전히 끝나고나서 트랜잭션2가 수행되는 것을 확인할 수 있다.
- Acquired Connection [Hikari... wrapping conn0] for JDBC transaction : 트랜잭션을 시작하고, 커넥션 풀에서 conn0 커넥션 획득
- Releasing JDBC Connenction [Hikari... wrapping conn0] after transaction : 트랜잭션을 커밋하고, 커넥션 풀에 conn0 커넥션을 반납
둘 이상의 트랜잭션이 동작하는 과정을 정리하자면 다음과 같다.
- 트랜잭션이 각각 수행되면서 사용되는 DB 커넥션도 서로 다르다.
- 이 경우 트랜잭션을 각자 관리하기 때문에 전체 트랜잭션을 묶을 수 없다.
- 예를 들어 트랜잭션1이 커밋하고, 트랜잭션2가 롤백하는 경우 트랜잭션1에서 저장한 데이터는 커밋되고, 트랜잭션2에서 저장한 데이터는 롤백된다.
트랜잭션 전파
위처럼 트랜잭션을 각각 사용하는 게 아니라 이미 진행중인 트랜잭션에 추가로 트랜잭션을 수행하면 어떻게 될까?
이런 경우 어떻게 동작할지 결정하는 것을 트랜잭션 전파(propagation)라고 한다.
스프링은 다양한 트랜잭션 전파 옵션을 제공하는데, 우선 기본 옵션인 REQUIRED를 기준으로 알아보도록 하자.
외부 트랜잭션(처음 시작된 트랜잭션)이 수행중이고, 아직 끝나지 않은 채 내부 트랜잭션(나중에 시작된 트랜잭션)이 수행되는 경우,
스프링은 외부 트랜잭션과 내부 트랜잭션을 묶어서 하나의 트랜잭션을 만들어주며, 내부 트랜잭션이 외부 트랜잭션에 참여해 동작한다.
이때 스프링은 이해를 돕기 위해 논리 트랜잭션과 물리 트랜잭션이라는 개념을 나눈다.
논리 트랜잭션 vs 물리 트랜잭션
- 논리 트랜잭션 : 트랜잭션 매니저를 통해 트랜잭션을 사용하는 단위, 논리 트랜잭션은 트랜잭션이 진행되는 중에 내부에 추가로 트랜잭션을 사용하는 경우에 나타남 (단순히 트랜잭션이 하나인 경우에는 둘을 구분하지 않음)
- 물리 트랜잭션 : 실제 데이터베이스에 적용되는 트랜잭션, 실제 커넥션을 통해 트랜잭션을 시작(setAutoCommit(false))하고 커밋 또는 롤백하는 단위
논리 트랜잭션은 하나의 물리 트랜잭션으로 묶이며, 원칙은 다음과 같다.
- 모든 논리 트랜잭션이 커밋되어야 물리 트랜잭션이 커밋된다.
- 하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션은 롤백된다.
예제를 통해 여러가지 상황에서 어떻게 동작하는지 확인해보자.
내부 커밋
@Test
void inner_commit() {
log.info("외부 트랜잭션 시작");
TransactionStatus outer = txManager.getTransaction(new DefaultTransactionAttribute());
log.info("outer.isNewTransaction()={}", outer.isNewTransaction()); // true
log.info("내부 트랜잭션 시작");
TransactionStatus inner = txManager.getTransaction(new DefaultTransactionAttribute());
log.info("inner.isNewTransaction()={}", inner.isNewTransaction()); // false
log.info("내부 트랜잭션 커밋");
txManager.commit(inner);
log.info("외부 트랜잭션 커밋");
txManager.commit(outer);
}
- 외부 트랜잭션은 처음 수행된 트랜잭션으로 신규 트랜잭션이 된다.(isNewTansaction=true)
- 내부 트랜잭션을 시작하는 시점에 이미 외부 트랜잭션이 진행중인 상태이므로 내부 트랜잭션은 외부 트랜잭션에 참여하며, 이 경우 신규 트랜잭션이 아니다. (isNewTransaction=false)
- 외부 트랜잭션을 시작하거나 커밋할 때는 DB 커넥션을 통한 물리 트랜잭션을 시작, 커밋하는 로그를 확인할 수 있다.
- 내부 트랜잭션을 시작하거나 커밋할 때는 DB 커넥션을 통해 커밋하는 로그를 전혀 확인할 수 없다.
만약 내부 트랜잭션이 실제 물리 트랜잭션을 커밋한다면 트랜잭션이 끝나버리기 때문에 트랜잭션을 시작한 외부 트랜잭션까지 이어갈 수 없다.
따라서 내부 트랜잭션은 DB 커넥션을 통한 물리 트랜잭션을 커밋하면 안된다.
스프링은 이러한 중복 커밋 문제를 해결하기 위해 여러 트랜잭션이 함께 사용되는 경우 처음 트랜잭션을 시작한 외부 트랜잭션이 실제 물리 트랜잭션을 관리하도록 한다.
❔ 내부 트랜잭션이 외부 트랜잭션에 참여한다는 의미
• 내부 트랜잭션이 외부 트랜잭션을 그대로 이어 받아 따른다는 뜻
• 외부에서 시작된 물리 트랜잭션의 범위가 내부 트랜잭션까지 넓어진다는 뜻
트랜잭션 전파가 동작하는 과정을 정리하자면 다음과 같다.
- 외부 트랜잭션 요청
- txManager.getTransacion()를 호출해 외부 트랜잭션을 시작
- 트랜잭션 매니저는 데이터소스를 통해 커넥션을 생성
- 생성한 커넥션을 수동 커밋 모드(setAutoCommit(false))로 설정하며 물리 트랜잭션을 시작
- 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관
- 트랜잭션 매니저는 트랜잭션을 생성한 결과를 Transaction에 담아 반환하는데, 여기에 신규 트랜잭션 여부가 담겨있어 isNewTransaction()을 통해 확인 가능
- 로직1이 사용되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 트랜잭션이 적용된 커넥션을 획득하여 사용
- 내부 트랜잭션 요청
- txManager.getTransaction()을 호출해 내부 트랜잭션을 시작
- 트랜잭션 매니저는 트랜잭션 동기화 매니저를 통해 기존 트랜잭션이 존재하는지 확인
- 존재하면, 새로운 커넥션을 생성하지 않고 기존 트랜잭션에 참여
- 기존 트랜잭션에 참여했기 때문에 isNewTransaction() 결과가 false
- 로직2가 사용되고, 커넥션이 필요한 경우 트랜잭션 동기화 매니저를 통해 외부 트랜잭션이 보관한 커넥션을 획득하여 사용
- 내부 트랜잭션 응답
- 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 커밋
- 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작, 내부 트랜잭션은 신규 트랜잭션이 아니기 때문에 실제 커밋을 호출하지 않음 (물리 트랜잭션은 외부 트랜잭션이 종료될 때까지 이어져야 함)
- 외부 트랜잭션 응답
- 로직1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋
- 외부 트랜잭션은 신규 트랜잭션이기 때문에 DB 커넥션에 실제 커밋을 호출
- 실제 데이터베이스에 커밋이 반영되고, 물리 트랜잭션이 끝남
외부 롤백
내부 트랜잭션은 커밋되는데, 외부 트랜잭션이 롤백되는 상황에 대해 알아보자.
논리 트랜잭션이 하나라도 롤백되면, 전체 물리 트랜잭션은 롤백된다.
따라서 내부 트랜잭션을 커밋했어도, 내부 트랜잭션 안에서 저장한 데이터도 모두 함께 롤백된다.
코드로 확인해보자.
@Test
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);
}
- 외부 트랜잭션이 물리 트랜잭션을 시작하고 롤백하는 것을 확인할 수 있다.
- 내부 트랜잭션은 앞서 말한대로 직접 물리트랜잭션에 관여하지 않는다.
- 결과적으로 외부 트랜잭션에서 시작한 물리 트랜잭션의 범위가 내부 트랜잭션까지 사용되며, 외부 트랜잭션이 롤백되면서 전체 내용은 모두 롤백된다.
내부 롤백
이번엔 내부 트랜잭션은 모두 롤백되는데, 외부 트랜잭션이 커밋되는 상황이다.
내부 트랜잭션을 롤백 했지만 외부 트랜잭션은 커밋한다면, 지금까지 알아본 내용을 돌아봤을 때 외부 트랜잭션만 물리 트랜잭션에 영향을 주기 때문에 물리 트랜잭션이 커밋될 것처럼 생각된다.
하지만 하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션은 롤백되어야 한다.
스프링은 이러한 문제를 어떻게 해결하는지 코드로 확인해보자.
@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("외부 트랜잭션 커밋");
txManager.commit(outer);
}
- 내부 트랜잭션 롤백
- Participating transaction failed - making existing transaction as rollback-only
- 내부 트랜잭션을 롤백하면 실제 물리 트랜잭션은 롤백하지 않는다. 대신 기존 트랜잭션을 롤백 전용으로 표시한다.
- 외부 트랜잭션 커밋
- Global transaction is marked as rollback-only
- 커밋을 호출했지만, 전체 트랜잭션이 롤백 전용으로 표시되어 있어 물리 트랜잭션을 롤백한다.
트랜잭션 전파가 동작하는 과정을 정리하자면 다음과 같다.
- 내부 트랜잭션 응답
- 로직2가 끝나고 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백
- 트랜잭션 매니저는 롤백 시점에 신규 트랜잭션 여부에 따라 다르게 동작, 내부 트랜잭션의 경우 신규 트랜잭션이 아니기 때문에 실제 롤백을 호출하지 않음
- 내부 트랜잭션은 물리 트랜잭션을 롤백하지 않는 대신에 트랜잭션 동기화 매니저에 rollbackOnly=true 표시
- 외부 트랜잭션 응답
- 로직1이 끝나고 트랜잭션 매니저를 통해 외부 트랜잭션을 커밋
- 트랜잭션 매니저는 커밋 시점에 신규 트랜잭션 여부에 따라 다르게 동작, 외부 트랜잭션의 경우 신규 트랜잭션이기 때문에 DB 커넥션에 실제 커밋을 호출해야 함
- 실제 커밋을 호출하기 이전에 트랜잭션 동기화 매니저에 롤백 전용 표시(rollbackOnly=true)가 있는지 확인, 있으면 물리 트랜잭션을 커밋하지 않고 롤백
- 실제 데이터베이스에 롤백이 반영되고, 물리 트랜잭션 종료
- 트랜잭션 매니저에 커밋을 호출한 개발자 입장에서는 커밋을 기대했지만 롤백 전용 표시로 인해 실제로는 기대하지 않은 롤백이 되었기 때문에 UnexpectedRollbackException 예외 전달
정리
- 논리 트랜잭션이 하나라도 롤백되면 물리 트랜잭션은 롤백된다.
- 내부 논리 트랜잭션이 롤백되면 롤백 전용 마크(rollbackOnly=true)를 표시한다.
- 외부 트랜잭션을 커밋할 때 롤백 전용 마크를 확인해, 표시되어 있으면 물리 트랜잭션을 롤백한 뒤 UnexpectedRollbackException 예외를 던진다.
트랜잭션 전파 옵션
스프링은 다양한 트랜잭션 전파 옵션을 제공한다.
만약 별도의 설정을 하지 않으면 기본적으로 REQUIRED가 사용된다.
실무에서는 대부분 REQUIRED 옵션을 사용하고, 아주 가끔 REQUIRES_NEW 옵션을 사용한다.
나머지 옵션은 거의 사용하지 않아 가볍게 알아두고 필요할 때 찾아보면 된다.
| 옵션 | 설명 |
| REQUIRED | 기존 트랜잭션 없음 : 새로운 트랜잭션 생성 기존 트랜잭션 있음 : 기존 트랜잭션 참여 |
| REQUIRES_NEW | 기존 트랜잭션 없음 : 새로운 트랜잭션 생성 기존 트랜잭션 있음 : 새로운 트랜잭션 생성 |
| SUPPROT | 기존 트랜잭션 없음 : 트랜잭션 없이 진행 기존 트랜잭션 있음 : 기존 트랜잭션 참여 |
| NOT_SUPPROT | 기존 트랜잭션 없음 : 트랜잭션 없이 진행 기존 트랜잭션 있음 : 트랜잭션 없이 진행 (기존 트랜잭션 보류) |
| MANDATORY | 기존 트랜잭션 없음 : IllegalTrassactionStateException 예외 발생 기존 트랜잭션 있음 : 기존 트랜잭션 참여 |
| NEVER | 기존 트랜잭션 없음 : 트랜잭션 없이 진행 기존 트랜잭션 있음 : IllegalTrassactionStateException 예외 발생 |
| NESTED | 기존 트랜잭션 없음 : 새로운 트랜잭션 생성 기존 트랜잭션 있음 : 중첩 트랜잭션 생성 |
REQUIRES_NEW
외부 트랜잭션과 내부 트랜잭션을 완전히 분리해서 각각 별도의 물리 트랜잭션을 사용하는 방법이다.
- 물리 트랜잭션을 분리하려면 내부 트랜잭션을 시작할 때 REQUIRES_NEW 옵션을 주면 된다.
- 외부 트랜잭션과 내부 트랜잭션이 각각 별도의 물리 트랜잭션을 가짐 (DB 커넥션을 따로 사용)
- 커밋과 롤백이 각각 별도로 이뤄져 내부 트랜잭션에 문제가 발생해 롤백하더라도 외부 트랜잭션에 영향을 주지 않음
- 로직2는 롤백되고, 로직1은 커밋된다.
코드로 알아보자.
@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);
}
- 외부 트랜잭션 시작
- 외부 트랜잭션을 시작해 conn0을 획득하고 manual commit으로 변경해 물리 트랜잭션을 시작한다.
- 외부 트랜잭션은 신규 트랜잭션이다.
- 내부 트랜잭션 시작
- 내부 트랜잭션 시작 시 전파 옵션으로 PROPAGATION_REQUIRES_NEW 옵션을 사용하면 내부 트랜잭션을 시작할 때 기존 트랜잭션에 참여하는 것이 아니라 새로운 물리 트랜잭션을 만들어서 시작한다.
- 따라서 기존에 있는 conn0은 잠시 미뤄두고(Suspending), 새로운 conn1을 획득하여 manual commit으로 변경해 물리 트랜잭션을 시작한다.
- 내부 트랜잭션도 완전히 새로운 신규 트랜잭션으로 생성된다.
- 내부 트랜잭션 롤백
- 내부 트랜잭션이 신규 트랜잭션이므로 실제 물리 트랜잭션(conn1)을 롤백한다.
- 외부 트랜잭션 커밋
- 외부 트랜잭션이 신규 트랜잭션이므로 실제 물리 트랜잭션(conn0)을 커밋한다.
트랜잭션 전파가 동작하는 과정을 정리하자면 다음과 같다.
- 외부 트랜잭션 요청
- 외부 트랜잭션을 통해 물리 트랜잭션을 시작한다.
- 트랜잭션 매니저는 커넥션을 생성하고 수동 커밋 모드로 설정해 물리 트랜잭션을 시작한다.
- 트랜잭션 동기화 매니저에 커넥션을 보관한다.
- 로직1 사용
- 내부 트랜잭션 요청
- REQUIRES_NEW 옵션과 함께 내부 트랜잭션을 시작한다.
- 트랜잭션 매니저는 옵션을 확인하고, 기존 트랜잭션에 참여하는 것이 아니라 새로운 트랜잭션을 시작한다.
- 트랜잭션 매니저는 커넥션을 생성하고 수동 커밋 모드로 설정해 물리 트랜잭션을 시작한다.
- 트랜잭션 동기화 매니저에 커넥션을 보관한다.
- 이때 con1은 잠시 보류되고, con2가 사용된다. (내부 트랜잭션을 완료할 때까지 con2 사용)
- 로직2 사용
- REQUIRES_NEW 옵션과 함께 내부 트랜잭션을 시작한다.
- 내부 트랜잭션 응답
- 로직2가 끝나면 트랜잭션 매니저를 통해 내부 트랜잭션을 롤백한다.
- 내부 트랜잭션이 신규 트랜잭션이므로 실제 롤백을 호출한다.
- 내부 트랜잭션이 con2 물리 트랜잭션을 롤백하고, con2는 종료되거나 커넥션 풀에 반납된다.
- con1의 보류가 끝나고 다시 con1을 사용한다.
- 외부 트랜잭션 응답
- 외부 트랜잭션에 커밋을 요청한다.
- 외부 트랜잭션은 신규 트랜잭션이므로 물리 트랜잭션을 커밋한다.
- 이때 rollbackOnly 설정을 확인한다. 없으므로 커밋한다.
- 외부 트랜잭션이 con1 물리 트랜잭션을 커밋하고, con1은 종료되거나 커넥션 풀에 반납된다.
'🌱 Spring > DB 접근 기술' 카테고리의 다른 글
| 트랜잭션 이해하기 (0) | 2023.06.01 |
|---|---|
| 데이터 접근 기술 (SQL Mapper 기술 - JdbcTemplate, MyBatis) (0) | 2023.03.10 |
| 커넥션 풀(Connection Pool) (0) | 2023.03.02 |
