개요
데이터베이스의 트랜잭션 고립 수준에 대해 공부하다가 스프링에서 트랜잭션이 부모와 자식 사이에 전파가 된다는 사실을 알았습니다. 여러 가지 전파 수준이 있는데, 수준에 따라서 어떻게 결과가 달라지는지 궁금해서 테스트를 통해 알아보도록 하겠습니다.
트랜잭션 커밋과 롤백
트랜잭션 시작 시 Hikari에서 커넥션(Connection)을 가져오고 커밋을 하면 Hikari에 커넥션을 반납합니다.
또한, 롤백도 마찬가지로 반영된 내용을 모두 롤백하고 Hikari에 커넥션을 반납합니다.
만약에 아래 코드처럼 첫번째 트랜잭션이 커밋되고, 두번째 트랜잭션이 롤백된다면 트랜잭션 사용은 어떻게 될까요?
@Test
void double_commit() {
log.info("트랜잭션1 시작");
TransactionStatus tx1 = txManager.getTransaction(new DefaultTransactionAttribute());
log.info("트랜잭션2 커밋");
txManager.commit(tx1);
log.info("트랜잭션2 시작");
TransactionStatus tx2 = TxManager.getTransaction(new DefaultTransactionAttribute());
log.info("트랜잭션2 롤백");
txManager.rollback(tx2);
}
1. 트랜잭션1에서 먼저 커넥션을 사용하고 커밋 후 반납합니다.
2. 트랜잭션2에서 커넥션을 새롭게 사용하고 롤백 후 반납합니다.
즉, 2개는 별도의 트랜잭션이 동기적으로 작동합니다.
트랜잭션 전파란?
트랜잭션 전파란 하나의 트랜잭션 내부에 다른 트랜잭션이 있는 경우, 트랜잭션 정책에 따라 어떻게 동작할지 결정하는 것입니다. 스프링은 트랜잭션 범위를 정하기 위해 추상화된 AOP인 @Transactional을 사용합니다. 트랜잭션 내부에 트랜잭션이 존재하는 경우 경우(트랜잭션이 외부 혹은 내부에만 존재할 수도 있음) 트랜잭션 전파 수준에 따라 트랜잭션을 새로 만들 수도 있고, 롤백 범위도 달라집니다. 기본은 REQUIRED입니다. 실무에서는 REQUIRED를 대부분 사용하고 REQUIES_NEW를 가끔씩 사용하기도 합니다. 나머지는 잘 사용하지 않습니다.
외부 트랜잭션 내에 내부 트랜잭션이 있는 경우, 전체는 크게 하나의 트랜잭션으로 묶입니다.
스프링은 이해를 돕기 위해서 각 로직에 있는 트랜잭션은 논리 트랜잭션, 논리 트랜재션들을 묶어 하나의 물리 트랜잭션이라 합니다. 논리 트랜잭션은 트랜잭션 동기화 매니저를 통해 트랜잭션을 사용하는 단위입니다. 물리 트랜잭션이 실제 데이터베이스에 적용되는 단위입니다.
*중요*
- 모든 논리 트랜잭션이 커밋 되어야 물리 트랜잭션이 커밋됩니다.
- 하나라도 논리 트랜잭션이 롤백되면 물리 트랜잭션 내에 있는 모든 트랜잭션은 롤백됩니다.
2번 규칙에 의해 내부 트랜잭션이 롤백 되었으므로, 외부 트랜잭션이 커밋되더라도 물리 트랜잭션은 롤백됩니다.
스프링은 트랜잭션이 여러 개인 경우, 첫 논리 트랜잭션이 물리 트랜잭션을 시작시키며 최종 커밋합니다. 왜냐하면 내부 논리 트랜잭션이 커밋하면 물리 트랜잭션이 끝나버리기 때문입니다. 따라서, 외부 논리 트랜잭션은 DB 커넥션을 이용해 커밋을 하며 내부 논리 트래잭션은 외부 논리 트랜잭션에 참여만 합니다.
아래의 코드로 확인해보겠습니다.
트랜잭션 전파 동작 순서
외부 트랜잭션과 내부 트랜잭션 총 2개가 커밋하는 코드와 그림으로 트랜잭션 전파 동작 순서를 알아보겠습니다.
@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);
}
결과는 아래와 같습니다.
외부 트랜잭션 시작
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
외부 트랜잭션이 시작하면서 커넥션을 획득(Acquired Connection) 및 새로운 트랜잭션을 시작합니다.(outer.isNewTransaction()=true) 처음 시작되는 논리 트랜잭션이 물리 트랜잭션을 시작하기 때문입니다. 내부 트랜잭션은 외부 트랜잭션에 참여만 하고(Participating in existing transaction) 새로운 트랜잭션을 시작하지 않습니다.(inner.isNewTransaction()=false)
내부 트랜잭션은 외부 트랜잭션에 참여하기 때문에 내부 트랜잭션 커밋 이후에 아무런 커넥션 작업이 발생하지 않습니다.
트랜잭션 전파가 실제 어떻게 동작하는지 그림으로 알아보겠습니다.
외부 트랜잭션코드가 실행되고 이어서 내부 트랜잭션 코드가 실행됩니다. 외부 트랜잭션 코드는 이전에 스프링 트랜잭션 작동 원리 순서와 동일합니다. 내부 트랜잭션의 경우(REQUIRED) 신규 트랜잭션을 시작하지 않고 기존 트랜잭션이 있으면 기존 트랜잭션에 참여합니다. 트랜잭션 동기화 매니저에 외부 트랜잭션 로직을 수행했던 커넥션이 보관되어 있습니다. 이 커넥션을 내부 트랜잭션에서 그대로 사용합니다.
외부 트랜잭션이 신규 트랜잭션을 처음 시작하므로 물리 트랜잭션을 관리합니다. 내부 트랜잭션의 경우(REQUIRED) 기존 트랜잭션에 그대로 참여하기 때문에 커밋을 하더라도 물리 트랜잭션을 커밋하지 못합니다. 내부 트랜잭션이 모두 완료되고 외부 트랜잭션이 커밋을 할 때 DB 커넥션에 실제 커밋을 호출합니다.
외부 롤백 트랜잭션 전파 순서
외부 트랜잭션이 롤백되면 물리 트랜잭션은 전체 롤백됩니다.
외부 롤백 흐름은 아래 그림과 같습니다.
내부 트랜잭션의 경우(REQUIRED) 신규 트랜잭션을 시작하지 않고 기존 트랜잭션에 참여합니다. 또한 내부 트랜잭션이 커밋되어도 신규 트랜잭션에 커밋을 호출하지 않습니다.
외부 트랜잭션의 경우 롤백을 요청하면 트랜잭션 매니저는 실제 DB 커넥션에 롤백을 호출합니다. 따라서 실제 데이터베이스에 롤백이 적용되고 트랜잭션을 종료합니다.
내부 롤백 트랜잭션 전파 순서
내부 트랜잭션이 롤백되면 물리 트랜잭션은 전체 롤백됩니다. 단, 이 경우에는 외부 롤백 트랜잭션보다 조금 더 복잡합니다.
내부 트랜잭션의 경우(REQUIRED) 롤백이 발생하면 트랜잭션 동기화 매니저에 rollbackOnly=true를 표시합니다. 하지만 기존 트랜잭션에 참여하고 있기 때문에 실제 DB 커넥션에 롤백을 호출하지 않습니다.
외부 트랜잭션의 경우 실제 커밋을 호출하기 위해 트랜잭션 동기화 매니저에서 커넥션을 획득해야 하는데 rollbackOnly=true로 표시되어 있기 때문에 커밋을 하지 못하고 롤백을 합니다. 또한 단순히 롤백 할 뿐만 아니라 UnexpectedRollbackException을 던집니다. 시스템 입장에서는 커밋을 호출했지만, 롤백이 되었다는 것을 명확히 알려주기 위함입니다.
내부 롤백에도 외부에 영향주지 않는 방법
- REQUIRES_NEW 사용
첫째로 REQUIRES_NEW 정책을 사용해야 합니다. 외부와 내부 각각 별도의 트랜잭션이 생성되기 때문에 서로 독립적이므로 롤백이 영향을 주지 않습니다.(Suspending current transaction)
기본 트랜잭션 전파 전략의 경우(REQUIRED) 트랜잭션 동기화 매니저에서 1개의 커넥션을 사용하지만, REQUIRES_NEW 정책의 경우 각각 커넥션을 생성하여 총 2개의 커넥션을 사용하므로 서로 영향을 주지 않습니다. 커넥션을 2개나 사용하므로 커넥션 관리에 주의를 해야합니다.
- 트랜잭션 분리
둘째는 기존의 구조를 변경해 트랜잭션을 묶지 않고 분리합니다. 기존에는 외부 트랜잭션, 내부트랜잭션으로 하나의 물리 트랜잭션으로 묶였지만, 트랜잭션을 묶지 않은 채 별도의 트랜잭션을 가진 클래스에서 메서드가 호출된다면 물리 트랜잭션이 2개로 분리됩니다. 따라서 다른 커넥션을 사용하며 롤백을 해도 서로 영향을 미치지 않습니다.
핵심은 전파 속성에 따른 "롤백 유무"이다
스프링 트랜잭션 전파의 핵심은 롤백이 아닐까 생각합니다. 중첩된 여러개의 트랜잭션이 롤백될 때 어떻게 동작하는지 이해하고 설계하는 것이 핵심입니다. NESTED는 내부의 예외가 외부까지 전파가 되지 않는데, 해당 기능은 JPA에는 적용이 되지 않는 단점이 있습니다.
이와 관련해서 이미 우아한 형제에서는 관련 포스팅이 있습니다.
응? 이게 왜 롤백되는 거지? (https://techblog.woowahan.com/2606/)
예외 발생 시, 예외를 처리하는 @ControllerAdvice를 선택할 것인지, 나를 호출한 곳으로 다시 예외를 던질지, 아니면 애초에 서비스 로직을 분리해서 서로가 트랜잭션 전파에 영향이 없도록 할 것인지 전략을 세우고 그에 따라 전파 수준을 결정하면 됩니다.
*참고
스프링 DB 2편 - 데이터 접근 활용 기술(김영한님 강의)
'Spring 정리 > Spring JPA' 카테고리의 다른 글
| 트랜잭션 전파 전략 7개 (0) | 2022.12.03 |
|---|---|
| 스프링 트랜잭션 추상화, 동기화 (0) | 2022.11.30 |
| OSIV (0) | 2022.10.01 |
| 일반 Join vs Fetch Join (0) | 2022.06.29 |
| JPA를 이용해 History 테이블 자동 생성하기 (1) | 2021.12.14 |
