[Spring DB](7) 스프링 트랜잭션
스프링 트랜잭션을 더 깊이있게 파헤쳐보자.
스프링 트랜잭션 추상화
JDBC 기술을 사용하다가 JPA 기술로 변경하게 되면 트랜잭션을 사용하는 코드도 모두 변경해야한다. 이러한 문제를 해결하기 위해 트랜잭션 추상화를 통해 둘을 동일한 방식으로 사용할 수 있다. 스프링은 PlatformTransactionManager라는 인터페이스를 통해 트랜잭션을 추상화한다.
스프링은 트랜잭션을 추상화해서 제공할 뿐만 아니라, 실무에서 주로 사용하는 데이터 접근 기술에 대한 트랜잭션 매니저의 구현체도 제공한다. 개발자는 필요한 구현체를 스프링 빈으로 등록하고 주입받아서 사용하기만 하면 된 다.
여기에 더해서 스프링 부트는 어떤 데이터 접근 기술을 사용하는지를 자동으로 인식해서 적절한 트랜잭션 매니저를 선택해서 스프링 빈으로 등록해주기 때문에 트랜잭션 매니저를 선택하고 등록하는 과정도 생략할 수 있다. 예를 들어서 JdbcTemplate, MyBatis를 사용하면
DataSourceTransactionManager(JdbcTransactionManager)를 스프링 빈으로 등록하고, JPA를 사용하면JpaTransactionManager를 스프링 빈으로 등록해준다.
프록시 방식의 AOP
트랜잭션 프록시 적용 전
//트랜잭션 시작
TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
try {
//비즈니스 로직
bizLogic(fromId, toId, money);
transactionManager.commit(status); //성공시 커밋
} catch (Exception e) {
transactionManager.rollback(status); //실패시 롤백
throw new IllegalStateException(e);
}트랜잭션을 처리하기 위한 프록시를 도입하기 전에는 서비스의 로직에서 트랜잭션을 직접 시작했다.
트랜잭션 프록시 적용 후
public class TransactionProxy {
private MemberService target;
public void logic() {
//트랜잭션 시작
TransactionStatus status = transactionManager.getTransaction(..);
try {
//실제 대상 호출
target.logic();
transactionManager.commit(status); //성공시 커밋
} catch (Exception e) {
transactionManager.rollback(status); //실패시 롤백
throw new IllegalStateException(e);
}
}
}트랜잭션을 처리하기 위한 프록시를 적용하면 트랜잭션을 처리하는 객체와 비즈니스 로직을 처리하는 서비스 객체를 명확하게 분리할 수 있다.
트랜잭션 프록시 적용 후 서비스 코드
public class Service {
public void logic() {
//트랜잭션 관련 코드 제거, 순수 비즈니스 로직만 남음
bizLogic(fromId, toId, money);
}
}트랜잭션 프록시가 트랜잭션 처리 로직을 모두 가져간다. 트랜잭션을 시작한 후에 실제 서비스를 대신 호출한다. 트랜잭션 프록시 덕분에 서비스 계층에는 순수한 비즈니즈 로직만 남길 수 있다.
트랜잭션 적용 확인 테스트
package hello.springtx.apply;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.aop.support.AopUtils;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.context.TestConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.support.TransactionSynchronizationManager;
import static org.assertj.core.api.Assertions.*;
@Slf4j
@SpringBootTest
public class TxBasicTest {
@Autowired
BasicService basicService;
@Test
void proxyCheck() {
log.info("aop class={}", basicService.getClass());
assertThat(AopUtils.isAopProxy(basicService)).isTrue();
}
@Test
void txTest() {
basicService.tx();
basicService.nonTx();
}
@TestConfiguration
static class TxApplyBasicConfig {
@Bean
BasicService basicService() {
return new BasicService();
}
}
@Slf4j
static class BasicService {
@Transactional
public void tx() {
log.info("call tx");
boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();
log.info("tx active={}", txActive);
}
public void nonTx() {
log.info("call nonTx");
boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();
log.info("tx active={}", txActive);
}
}
}AopUtils.isAopProxy(): 선언적 트랜잭션 방식에서 스프링 트랜잭션은 AOP를 기반으로 동작한다. @Transactional을 메서드나 클래스에 붙이면 해당 객체는 트랜잭션 AOP 적용의 대상이 되고, 결과적으로 실제 객체 대신에 트랜잭션을 처리해주는 프록시 객체가 스프링 빈에 등록된다. 그리고 주입을 받을 때도 실제 객체 대신에 프록시 객체가 주입된다.
트랜잭션 적용 위치에 따른 우선순위
항상 더 구체적이고 자세한 것이 높은 우선순위를 가진다.
package hello.springtx.apply;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.context.TestConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.support.TransactionSynchronizationManager;
@SpringBootTest
public class TxLevelTest {
@Autowired
LevelService service;
@Test
void orderTest() {
service.write();
service.read();
}
@TestConfiguration
static class TxLevelTestConfig {
@Bean
LevelService levelService() {
return new LevelService();
}
}
@Slf4j
@Transactional(readOnly = true)
static class LevelService {
@Transactional(readOnly = false)
public void write() {
log.info("call write");
printTxInfo();
}
public void read() {
log.info("call read");
printTxInfo();
}
private void printTxInfo() {
boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();
log.info("tx active={}", txActive);
boolean readOnly = TransactionSynchronizationManager.isCurrentTransactionReadOnly();
log.info("tx readOnly={}", readOnly);
}
}
}<우선순위>
: 클래스의 메서드 > 클래스의 타입 > 인터페이스의 메서드 > 인터페이스의 타입
인터페이스에서 @Transactional 은 스프링 공식 메뉴얼에서 권장하는 방식이 않으니, 가급적 구체 클래스에 사용하자.
**프록시 내부 호출
트랜잭션 AOP는 기본적으로 프록시 방식의 AOP를 사용한다.
@Transactional을 적용하면 프록시 객체가 요청을 먼저 받아서 트랜잭션을 처리하고, 실제 객체를 호출해준다. 따라서 트랜잭션을 적용하려면 항상 프록시를 통해서 대상 객체(Target)을 호출해야 한다. 이렇게 해야 프록시에서 먼저 트랜잭션을 적용하고, 이후에 대상 객체를 호출하게 된다. 만약 프록시를 거치지 않고 대상 객체를 직접 호출하게 되면 AOP가 적용되지 않고, 트랜잭션도 적용되지 않는다.
AOP를 적용하면 스프링은 실제 객체 대신 프록시 객체를 스프링 빈으로 등록한다. 프록시 객체가 주입되기 때문에 대상 객체를 직접 호출하는 문제는 일반적으로 발생하지 않는다. 하지만 대상 객체의 내부에서 메서드 호출이 발생하면 프록시를 거치지 않고 대상 객체를 직접 호출하는 문제가 발생한다. 이렇게 되면 트랜잭션이 적용되지 않는다.
내부 호출이 발생하는 테스트를 만들어보자.
package hello.springtx.apply;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.context.TestConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.support.TransactionSynchronizationManager;
@Slf4j
@SpringBootTest
public class InternalCallV1Test {
@Autowired
CallService callService;
@Test
void printProxy() {
log.info("callService class={}", callService.getClass());
}
@Test
void internalCall() {
callService.internal();
}
@Test
void externalCall() {
callService.external();
}
@TestConfiguration
static class InternalCallV1TestConfig {
@Bean
CallService callService() {
return new CallService();
}
}
@Slf4j
static class CallService {
public void external() {
log.info("call external");
printTxInfo();
internal();
}
@Transactional
public void internal() {
log.info("call internal");
printTxInfo();
}
private void printTxInfo() {
boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();
log.info("tx active={}", txActive);
}
}
}CallService의 external()은 트랜잭션이 없고, internal()은 트랜잭션을 적용한다. @Transactional이 하나라도 있으면 프록시 객체가 만들어지기 때문에 프록시 객체가 대신 주입된다.
printProxy() 테스트 코드를 실행해보니 CGLIB가 붙은 프록시 객체를 주입받은 결과를 확인할 수 잇다.
callService class=class hello..InternalCallV1Test$CallService$$EnhancerBySpringCGLIB$$4ec3f332
internalCall() 테스트 코드를 실행해도 프록시가 트랜잭션을 적용한 것을 확인할 수 있다.
TransactionInterceptor : Getting transaction for [hello.springtx.apply.InternalCallV1Test$CallService.internal]
InternalCallV1Test$CallService : call internal
InternalCallV1Test$CallService : tx active=true
TransactionInterceptor : Completing transaction for [hello.springtx.apply.InternalCallV1Test$CallService.internal]tx active=true가 나왔다.
externalCall()을 실행해본다.
CallService : call external
CallService : tx active=false
CallService : call internal
CallService : tx active=false로그를 보면 트랜잭션 관련 코드가 없다. 예상과 다르게 internal()에 트랜잭션이 적용되지 않았다.
흐름을 분석해보면,
1. 클라이언트는 callService.external()을 호출한다.
2. callService는 internal()에 적용된 @Transactional 로 인해, 트랜잭션 프록시가 적용되어, 트랜잭션 프록시가 호출된다.
3. external()은 @Transactional 가 없기 때문에, 트랜잭션을 적용하지 않고, 실제 객체 인스턴스의 external()을 호출한다.
4. external()은 내부에서 internal()을 호출한다.
5. internal()은 자기 자신(this)을 실제 대상 객체(target)로 내부 호출한다. 결과적으로 target에 있는 internal()을 직접 호출한 것이다.
6. 이러한 내부 호출은 프록시를 거치지 않는다.
=> 프록시를 사용하면 메서드 내부 호출에 프록시를 적용할 수 없다.
문제 해결을 위해 internal() 메서드를 별도의 클래스로 분리해본다.
package hello.springtx.apply;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.context.TestConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.support.TransactionSynchronizationManager;
@Slf4j
@SpringBootTest
public class InternalCallV2Test {
@Autowired
CallService callService;
@Test
void printProxy() {
log.info("callService class={}", callService.getClass());
}
@Test
void externalCall() {
callService.external();
}
@TestConfiguration
static class InternalCallV1TestConfig {
@Bean
CallService callService() {
return new CallService(internalService());
}
@Bean
InternalService internalService() {
return new InternalService();
}
}
@Slf4j
@RequiredArgsConstructor
static class CallService {
private final InternalService internalService;
public void external() {
log.info("call external");
printTxInfo();
internalService.internal();
}
private void printTxInfo() {
boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();
log.info("tx active={}", txActive);
}
}
@Slf4j
static class InternalService {
@Transactional
public void internal() {
log.info("call internal");
printTxInfo();
}
private void printTxInfo() {
boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();
log.info("tx active={}", txActive);
}
}
}InternalService 클래스를 만들고 internal() 메서드를 옮겨 메서드 내부 호출을 외부 호출로 변경했다.
CallService에는 트랜잭션 관련 코드가 전혀 없으므로 트랜잭션 프록시가 적용되지 않는다. InternalService에는 트랜잭션 관련 코드가 있으므로 트랜잭션 프록시가 적용된다.
실무에서는 이렇게 별도의 클래스로 분리하는 방법을 주로 사용한다.
주의사항 - 초기화 시점
트랜잭션은 스프링 초기화 시점에 적용되지 않을 수 있다.
package hello.springtx.apply;
import jakarta.annotation.PostConstruct;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.context.event.ApplicationReadyEvent;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.context.TestConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.context.event.EventListener;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.support.TransactionSynchronizationManager;
@SpringBootTest
public class InitTxTest {
@Autowired
Hello hello;
@Test
void go() {
//초기화 코드는 스프링이 초기화 시점에 호출한다.
}
@TestConfiguration
static class InitTxTestConfig {
@Bean
Hello hello() {
return new Hello();
}
}
@Slf4j
static class Hello {
@PostConstruct
@Transactional
public void initV1() {
boolean isActive = TransactionSynchronizationManager.isActualTransactionActive();
log.info("Hello init @PostConstruct tx active={}", isActive);
}
@EventListener(value = ApplicationReadyEvent.class)
@Transactional
public void init2() {
boolean isActive = TransactionSynchronizationManager.isActualTransactionActive();
log.info("Hello init ApplicationReadyEvent tx active={}", isActive);
}
}
}초기화 코드 @PostConstruct와 @Transactional을 함께 사용하면 트랜잭션이 적용되지 않는다. 왜냐하면 초기화 코드가 먼저 호출되고, 그 다음에 트랜잭션 AOP가 적용되기 때문이다. 따라서 초기화 시점에는 해당 메서드에서 트랜잭션을 획득할 수 없다.
가장 확실한 대안은 ApplicationReadyEvent를 사용하는 것이다.
init2()에서 사용했듯이, 이 이벤트는 트랜잭션 AOP를 포함한 스프링이 컨테이너가 완전히 생성되고 난 다음에 이벤트가 붙은 메서드를 호출해준다.
예외와 트랜잭션 커밋, 롤백
예외가 발생했는데 트랜잭션 범위 밖으로 예외를 던지면 어떻게 될까?
- 언체크 예외인 RuntimeException, Error와 그 하위 예외가 발생하면 트랜잭션을 롤백한다.
- 체크 예외인 Exception과 그 하위 예외가 발생하면 트랜잭션을 커밋한다.
package hello.springtx.exception;
import lombok.extern.slf4j.Slf4j;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.context.TestConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.transaction.annotation.Transactional;
import static org.assertj.core.api.Assertions.*;
@SpringBootTest
public class RollbackTest {
@Autowired
RollbackService service;
@Test
void runtimeException() {
assertThatThrownBy(() -> service.runtimeException())
.isInstanceOf(RuntimeException.class);
}
@Test
void checkedException() {
assertThatThrownBy(() -> service.checkedException())
.isInstanceOf(MyException.class);
}
@Test
void rollbackFor() {
assertThatThrownBy(() -> service.rollbackFor())
.isInstanceOf(MyException.class);
}
@TestConfiguration
static class RollbackTestConfig {
@Bean
RollbackService rollbackService() {
return new RollbackService();
}
}
@Slf4j
static class RollbackService {
// 런타임 예외 발생: 롤백
@Transactional
public void runtimeException() {
log.info("call runtimeException");
throw new RuntimeException();
}
//체크 예외 발생: 커밋
@Transactional
public void checkedException() throws MyException {
log.info("call checkedException");
throw new MyException();
}
//체크 예외 rollbackFor 지정: 롤백
@Transactional(rollbackFor = MyException.class)
public void rollbackFor() throws MyException {
log.info("call checkedException");
throw new MyException();
}
}
static class MyException extends Exception {
}
}runtimeException()
: RuntimeException이 발생하므로 트랜잭션이 롤백된다.
checkedException()
: MyException은 Exception을 상속받은 체크 예외이다. 따라서 예외가 발생해도 트랜잭션이 커밋된다.
스프링은 왜 체크 예외는 커밋하고, 언체크(런타임) 예외는 롤백할까?
스프링 기본적으로 체크 예외는 비즈니스 의미가 있을 때 사용하고, 런타임(언체크) 예외는 복구 불가능한 예외로 가정 한다.
주문을 하는데 상황에 따라 다음과 같이 조치한다.
1. 정상: 주문시 결제를 성공하면 주문 데이터를 저장하고 결제 상태를 '완료' 로 처리한다.
2. 시스템 예외: 주문시 내부에 복구 불가능한 예외가 발생하면 전체 데이터를 롤백한다.
3. 비즈니스 예외: 주문시 결제 잔고가 부족하면 주문 데이터를 저장하고, 결제 상태를 '대기' 로 처리한다.
- 이 경우 고객에게 잔고 부족을 알리고 별도의 계좌로 입금하도록 안내한다.
이때 결제 잔고가 부족하면 'NotEnoughMoneyException' 이라는 체크 예외가 발생한다고 가정한다. 이 예외는 시스템에 문제가 있어서 발생하는 시스템 예외가 아니다. 시스템은 정상 동작했지만, 비즈니스 상황에서 문제가 되기 때문에 발생한 예외이다. 비즈니스 예외는 매우 중요하고, 반드시 처리해야 하는 경우가 많으므로 체크 예외를 고려할 수 있다.
코드로 알아보도록 한다.
NotEnoughMoneyException
package hello.springtx.order;
public class NotEnoughMoneyException extends Exception {
public NotEnoughMoneyException(String message) {
super(message);
}
}
Order
package hello.springtx.order;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.Id;
import jakarta.persistence.Table;
import lombok.Getter;
import lombok.Setter;
@Entity
@Table(name = "orders")
@Getter
@Setter
public class Order {
@Id
@GeneratedValue
private Long id;
private String username; //정상, 예외, 잔고부족
private String payStatus; //대기, 완료
}
OrderRepository
package hello.springtx.order;
import org.springframework.data.jpa.repository.JpaRepository;
public interface OrderRepository extends JpaRepository<Order, Long> {
}
OrderService
package hello.springtx.order;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
@Slf4j
@Service
@RequiredArgsConstructor
public class OrderService {
private final OrderRepository orderRepository;
//JPA는 트랜잭션 커밋 시점에 Order 데이터를 DB에 반영한다.
@Transactional
public void order(Order order) throws NotEnoughMoneyException {
log.info("order 호출");
orderRepository.save(order);
log.info("결제 프로세스 진입");
if (order.getUsername().equals("예외")) {
log.info("시스템 예외 발생");
throw new RuntimeException("시스템 예외");
} else if (order.getUsername().equals("잔고 부족")) {
log.info("잔고 부족 비즈니스 예외 발생");
order.setPayStatus("대기");
throw new NotEnoughMoneyException("잔고가 부족합니다");
} else {
//정상 승인
log.info("정상 승인");
order.setPayStatus("완료");
}
log.info("결제 프로세스 완료");
}
}
OrderServiceTest
package hello.springtx.order;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import java.util.Optional;
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;
import static org.junit.jupiter.api.Assertions.*;
@Slf4j
@SpringBootTest
class OrderServiceTest {
@Autowired
OrderService orderService;
@Autowired
OrderRepository orderRepository;
@Test
void complete() throws NotEnoughMoneyException {
Order order = new Order();
order.setUsername("정상");
orderService.order(order);
Order findOrder = orderRepository.findById(order.getId()).get();
assertThat(findOrder.getPayStatus()).isEqualTo("완료");
}
@Test
void runtimeException() {
//given
Order order = new Order();
order.setUsername("예외");
//when, then
assertThatThrownBy(() -> orderService.order(order))
.isInstanceOf(RuntimeException.class);
//then: 롤백되었으므로 데이터가 없어야 한다.
Optional<Order> orderOptional = orderRepository.findById(order.getId());
assertThat(orderOptional.isEmpty()).isTrue();
}
@Test
void bizException() {
//given
Order order = new Order();
order.setUsername("잔고부족");
//when
try {
orderService.order(order);
fail("잔고 부족 예외가 발생해야 합니다.");
} catch (NotEnoughMoneyException e) {
log.info("고객에게 잔고 부족을 알리고 별도의 계좌로 입금하도록 안내");
}
//then
Order findOrder = orderRepository.findById(order.getId()).get();
assertThat(findOrder.getPayStatus()).isEqualTo("대기");
}
}complete()
: 모든 프로세스가 정상 수행된다. 데이터가 '완료' 상태로 저장되었는지 검증한다.
runtimeException()
: RuntimeException("시스템 예외")이 발생한다. 런타임 예외로 롤백이 수행되었기 때문에 'Order' 데이터가 비어 있는 것을 확인할 수 있다.
bizException()
: NotEnoughMoneyException("잔고가 부족합니다")이 발생한다. 체크 예외로 커밋이 수행되었기 때문에 'Order' 데이터가 저장된다.
데이터가 '대기' 상태로 잘 저장되었는지 검증한다.
NotEnoughMoneyException은 비즈니스 문제 상황을 예외를 통해 알려준다. 마치 예외가 리턴 값처럼 사용된다. 따라서 이 경우에는 트랜잭션을 커밋하는 것이 맞다. 이 경우 롤백하면 생성한 'Order' 자체가 사라진다. 그러면 고객에게 잔고 부족을 알리고 별도의 계좌로 입금하도록 안내해도 주문('Order') 자체가 사라지기 때문에 문제가 된다.
비즈니스 상황에 따라 체크 예외의 경우에도 트랜잭션을 커밋하지 않고, 롤백하고 싶을 수 있다. 이때는 rollbackFor 옵션을 사용하면 된다.
런타임 예외는 항상 롤백된다. 체크 예외의 경우 rollbackFor 옵션을 사용해서 비즈니스 상황에 따라서 커밋과 롤백을 선택하면 된다.
정리
트랜잭션을 적용한 내부 메서드 호출은 클래스를 분리해서 사용한다.
애플리케이션 초기화시 트랜잭션을 사용하려면 @EventListner(value = ApplicationReadyEvent.class)를 사용한다.
언체크 예외인 RuntimeException, Error와 그 하위 예외가 발생하면 트랜잭션을 롤백한다.
체크 예외인 Exception과 그 하위 예외가 발생하면 트랜잭션을 커밋한다.