Spring 트랜잭션은 언제 어떻게 롤백 될까? -1편

개요

스프링에서 @Transactional 어노테이션을 사용하면 트랜잭션이 자동으로 관리된다. 로직이 성공적으로 처리되면 commit을 통해 데이터베이스에 변경 사항이 반영되고, 오류가 발생하면 rollback을 통해 모든 변경 사항이 취소된다. 다만 이는 기본적인 개념으로 이번 글에서는 더 나아가 세부적으로 롤백이 정확히 언제 발생하고(1편), 특정 상황을 예시로 해당 로직이 롤백이 될지 안 될지에 대해 맞춰보는 식(2편)으로 알아보고자 한다.

 

 

Check Exception, Unchecked Exception

먼저 자바에서는 예외를 크게 다음과 같이 Exception과 Error 두 가지로 나누고 있다.

Exception & Error 계층구조

Exception은 입력 값에 대한 처리가 불가능하거나 프로그램 실행 중에 참조된 값이 잘못된 경우인 예외들을 의미하며, Error는 OutOfMemmoryError나 StackOverFlowError와 같이 프로그램이 중단될 수도 있는 심각한 에러를 의미한다. 

그리고 Exception 내부에서는 크게 다음과 같은 그룹으로 구분 짓는다.

• Checked Exception: RuntimeException 클래스와 전혀 관계없는 예외들(IoException, FileNotFoundException..)
• Unchecked Exception: RuntimeException 클래스 및 그 하위 클래스를 상속받는 예외들(NullPointerException, ClassCastException..)

Checked Exception은 컴파일 시점에서 반드시 처리해야 하는 예외로, 만약 try-catch로 처리하지 않거나 메서드 선언부에 throws로 예외를 던지지 않으면 다음과 같은 컴파일 오류가 발생한다.

unreported exception IOException; must be caught or declared to be thrown

반면 Unchecked Exception은 컴파일 시점이 아닌 실행 중에 발생할 수 있는 예외로, 컴파일 시점에서 예외 처리를 강제하지 않는다. 따라서 별도로 처리를 하지 않더라도 컴파일 시점에서는 정상적으로 진행된다.

JAVA 11을 기준으로 Chekced Exception, Unchecked Exception, 그리고 Error에 해당하는 클래스 목록은 다음 문서에서 확인할 수 있다.

• Exception.html
• RuntimeException.html
• Error.html

 

 

Spring @Transactionl과 Exception

이제 앞에서 살펴본 CheckedException과 UncheckedException에 따라 다르게 동작하는 @Transactional 애너테이션에 대해 알아보겠다.

스프링에서는 @Transactional 애너테이션을 사용하여 트랜잭션을 처리하는데, 이를 통해 내부적으로 프록시 객체를 생성하고, 메서드 실행 전후로 트랜잭션 관련 로직을 삽입하여 트랜잭션을 관리한다. 간단하게 말하면 메서드 실행 중 Exception이 발생하면 rollback을 수행하고, 정상적으로 실행되면 commit이 이루어지는 방식이다.

다만 여기서 정확하게 짚고 넘어가면 모든 Exception에 대해서 전부 롤백을 시키는 것은 아니다. 기본적으로 Error와 UncheckedException(즉, RuntimeException)에 대해서만 트랜잭션이 롤백되며, CheckedException은 기본적으로 롤백되지 않는다.(https://docs.spring.io/spring-framework/reference/data-access/transaction/declarative/rolling-back.html)

던져진 예외가 RuntimeException의 인스턴스 또는 서브클래스인 경우(Error도 기본적으로 롤백됨).

 

 

Rollback 과정

이제 롤백이 일어나는 과정에 대해 살펴볼 텐데, 핵심이 되는 부분들은 순서대로 크게 아래의 네 가지 함수들이다.

1. TransactionAspectSupport.invokeWithinTransaction()
2. TransactionAspectSupport.completeTransactionAfterThrowing()
3. RuleBasedTransactionAttribute.rollbackOn()
4. DefaultTransactionAttribute.rollbackOn()

그리고 아래의 5가지 동작을 살펴볼 것이다.

1. UncheckedException 발생 시 트랜잭션 동작
2. UncheckedException을 try-catch로 잡을 때 트랜잭션 동작
3. CheckedException 발생 시 트랜잭션 동작
4. CheckedException + rollbackFor시 트랜잭션 동작
5. UncheckedException + noRollbackFor시 트랜잭션 동작

 

1. UncheckedException 발생 시 트랜잭션 동작

@Service
public class OrderService {

    @Autowired
    private OrderRepository orderRepository;

    @Transactional
    public void processOrders(List<Order> orders) {
        for (Order order : orders) {
            validateOrder(order);
            orderRepository.save(order);
        }
    }

    private void validateOrder(Order order) {
        if (order.getAmount() < 0) {
            throw new IllegalArgumentException("Invalid order amount"); // Unchecked Exception
        }
    }
}

위 코드에서 processOrders 메서드는 주문 목록을 처리하는데, order.getAmount()가 0보다 작은 경우 IllegalArgumentException이 발생한다. 그리고 이 예외는 UncheckedException이므로 트랜잭션이 자동으로 롤백되어야 할 것이다.

 

내부 동작

일단 @Transactional이 적용된 메서드가 호출되면 스프링 내부적으로 TransactionAspectSupport.invokeWithinTransaction() 메서드가 실행된다. 이 메서드는 트랜잭션을 관리하고, 예외가 발생하면 트랜잭션을 롤백하는 역할을 한다.

TransactionAspectSupport.invokeWithinTransaction()

protected Object invokeWithinTransaction(Method method, Class<?> targetClass, InvocationCallback invocation) throws Throwable {
    TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
    
    Object retVal = null;
    try {
        // 실제 비즈니스 메서드 호출
        retVal = invocation.proceedWithInvocation();
    } catch (Throwable ex) {
        // 예외 발생 시 롤백 처리
        completeTransactionAfterThrowing(txInfo, ex);
        throw ex;
    } finally {
        // 트랜잭션 정리 작업
        cleanupTransactionInfo(txInfo);
    }
    commitTransactionAfterReturning(txInfo);
    return retVal;
}

invokeWithinTransaction()는 proceedWithInvocation()을 호출해 실제 비즈니스 메서드를 실행시킨다. 그리고 try-catch를 통해 이 과정에서 예외가 발생하면 completeTransactionAfterThrowing()가 호출되어 트랜잭션을 롤백할지 또는 커밋할지를 결정한다.

TransactionAspectSupport.completeTransactionAfterThrowing()

protected void completeTransactionAfterThrowing(@Nullable TransactionInfo txInfo, Throwable ex) {
    if (txInfo != null && txInfo.getTransactionStatus() != null) {
        if (txInfo.transactionAttribute.rollbackOn(ex)) { // 롤백 여부 판단
            txInfo.getTransactionManager().rollback(txInfo.getTransactionStatus());
        } else {
            txInfo.getTransactionManager().commit(txInfo.getTransactionStatus());
        }
    }
}

completeTransactionAfterThrowing()에서 중요한 부분은 txInfo.transactionAttribute.rollbackOn(ex)가 주어진 예외에 따라 트랜잭션을 롤백할지 커밋할지를 결정한다는 점이다. 이때 TransactionAttribute의 구현체는 RuleBasedTransactionAttribute가 들어가게 된다.

RuleBasedTransactionAttribute.rollbackOn()

@Override
public boolean rollbackOn(Throwable ex) {
    RollbackRuleAttribute winner = null; // 가장 적합한 롤백 규칙을 담을 변수
    int deepest = Integer.MAX_VALUE; // 계층 깊이를 추적하기 위한 변수 (작을수록 상위 클래스에 가까움)
 
    // 롤백 규칙이 존재하는 경우
    if (this.rollbackRules != null) {
        for (RollbackRuleAttribute rule : this.rollbackRules) {
            // 현재 예외의 상속 계층에서 이 규칙과 일치하는지 확인
            int depth = rule.getDepth(ex); 
            // 일치하는 규칙이 있으면, 해당 규칙의 깊이를 확인
            if (depth >= 0 && depth < deepest) {
                // 더 얕은(가까운) 깊이의 규칙이 있으면 그것을 winner로 설정
                deepest = depth;
                winner = rule;
            }
        }
    }
 
    // winner가 없다면 기본 규칙(UncheckedException 또는 Error일 때 롤백)을 적용
    if (winner == null) {
        return super.rollbackOn(ex); // 기본 롤백 규칙: RuntimeException 또는 Error일 경우 롤백
    }
 
    // winner가 NoRollbackRuleAttribute가 아니면 롤백, 맞다면 커밋
    return !(winner instanceof NoRollbackRuleAttribute);
}

롤백의 여부는 rollbackOn()에서 결정되는데, rollbackOn()은 스프링은 예외 타입을 검사하여 트랜잭션을 롤백할지 여부를 결정하며 기본적으로 RuntimeException 또는 Error가 발생했을 때 롤백이 수행된다. 

여기서 winner는 다음과 같은 역할을 한다.

• 발생한 예외에 가장 적합한 롤백 규칙을 찾는 역할을 담당한다.
• 예외의 상속 계층에서 가장 가까운 롤백 규칙(즉, 예외 계층 구조상 가장 얕은 깊이에 있는 규칙)을 선택한다.
• 예를 들어, 예외가 IllegalArgumentException일 때, IllegalArgumentException에 대한 규칙이 있으면 해당 규칙이 winner가 된다. 규칙이 없다면 상위 클래스인 RuntimeException에 대한 규칙을 찾는다.

만약 우리 예시처럼 winner가 없으면(null이면) 기본적으로 UncheckedException(RuntimeException)이나 Error에 대해 롤백을 수행하는 super.rollbackOn(ex) 메서드가 호출된다. 그리고 이 동작은 DefaultTransactionAttribute.rollBackOn()에서 처리된다.

DefaultTransactionAttribute.rollBackOn()

@Override
public boolean rollbackOn(Throwable ex) {
    return (ex instanceof RuntimeException || ex instanceof Error); // UncheckedException 또는 Error 시 롤백
}

rollbackOn()은 true로 반환되고 따라서 @Transactional 사용 시 UncheckedException(RuntimeException)을 별도로 처리하지 않으면 자동으로 롤백이 일어나게 된다.

 

2. UncheckedException을 try-catch로 잡을 때 트랜잭션 동작

이번에는 @Transactional을 사용하여 UncheckedException(즉, RuntimeException)이 발생했지만, 이를 try-catch로 처리했을 때 트랜잭션이 어떻게 동작하는지 살펴보자

@Service
public class OrderService {

    @Autowired
    private OrderRepository orderRepository;

    @Transactional
    public void processOrders(List<Order> orders) {
        for (Order order : orders) {
            validateOrderWithTryCatch(order);
            orderRepository.save(order);
        }
    }

    private void validateOrderWithTryCatch(Order order) {
        if (order.getAmount() < 0) {
            try {
                throw new IllegalArgumentException("Invalid order amount"); // Unchecked Exception
            } catch (IllegalArgumentException e) {
                e.printStackTrace(); // 예외를 try-catch로 처리하여 복구된 것으로 간주
            }
        }
    }
}

 

내부 동작

1번과 동일하게 TransactionAspectSupport.invokeWithinTransaction()가 실행된다.

TransactionAspectSupport.invokeWithinTransaction()

protected Object invokeWithinTransaction(Method method, Class<?> targetClass, InvocationCallback invocation) throws Throwable {
    TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
    
    Object retVal = null;
    try {
        // 실제 비즈니스 메서드 호출
        retVal = invocation.proceedWithInvocation();
    } catch (Throwable ex) {
        // 예외 발생 시 롤백 처리
        completeTransactionAfterThrowing(txInfo, ex);
        throw ex;
    } finally {
        // 트랜잭션 정리 작업
        cleanupTransactionInfo(txInfo);
    }
    commitTransactionAfterReturning(txInfo); // 예외가 없으므로 트랜잭션이 커밋됨
    return retVal;
}

다만 이번에는 비즈니스 로직에서 예외가 try-catch로 처리되었기 때문에, invokeWithinTransaction() 메서드의 catch 블록에서 감지되지 않는다. 따라서 completeTransactionAfterThrowing() 메서드가 호출되지 않아 트랜잭션은 정상적으로 커밋된다.

결론적으로 UncheckedException(즉, RuntimeException)이 발생하더라도 이를 try-catch로 처리하면 트랜잭션은 롤백되지 않고 커밋된다.

 

3. CheckedException 발생 시 트랜잭션 동작

CheckedException은 서두에서 언급했다시피 컴파일 시점에서 반드시 처리해야 하는 예외로, try-catch로 처리하지 않거나 메서드 선언부에 throws로 예외를 던지지 않으면 컴파일 에러가 발생한다. 결론먼저 보면 어떤 처리를 해주든 간에 기본 설정으로는 트랜잭션에서 CheckedException이 발생하더라도 트랜잭션은 롤백되지 않고 커밋된다. 다만 처리 방식에 따라 내부적으로 동작하는 과정은 다르니 한번 살펴보자.

ChckedException은 다음 두 가지로 나누어 처리할 수 있다.

• try-catch로 처리
• throws로 처리

 

try-catch로 처리

@Service
public class OrderService {

    @Autowired
    private OrderRepository orderRepository;

    @Transactional
    public void processOrders(List<Order> orders) {
        for (Order order : orders) {
            try {
                validateOrder(order);
                orderRepository.save(order);
            } catch (IOException e) {
                e.printStackTrace(); // CheckedException을 try-catch로 처리하여 트랜잭션에 영향을 주지 않음
            }
        }
    }

    private void validateOrder(Order order) throws IOException {
        // 주문 설명이 없으면 IOException을 발생시킴 (Checked Exception)
        if (order.getDescription() == null || order.getDescription().isEmpty()) {
            throw new IOException("Order description cannot be empty"); // Checked Exception
        }
    }
}

이 경우 트랜잭션 동작 방식은 2. UncheckedException을 try-catch로 잡을 때 트랜잭션 동작과 동일하게 처리된다.

TransactionAspectSupport.invokeWithinTransaction()가 실행되더라도 비즈니스 로직에서 예외가 try-catch로 처리되었기 때문에, invokeWithinTransaction() 메서드의 catch 블록에서 감지되지 않는다. 따라서 completeTransactionAfterThrowing() 메서드도 호출되지 않으며, 트랜잭션은 정상적으로 커밋된다.

 

throws로 처리

@Service
public class OrderService {

    @Autowired
    private OrderRepository orderRepository;

    @Transactional
    public void processOrders(List<Order> orders) throws IOException {
        for (Order order : orders) {
            validateOrder(order);
            orderRepository.save(order);
        }
    }

    private void validateOrder(Order order) throws IOException {
        // 주문 설명이 없으면 IOException을 발생시킴 (Checked Exception)
        if (order.getDescription() == null || order.getDescription().isEmpty()) {
            throw new IOException("Order description cannot be empty"); // Checked Exception
        }
    }
}

이번에는 메서드 선언부에 throws를 사용하여 예외를 상위 계층으로 계속해서 던졌다. 간단한 예시라 서비스만 언급했지만 컨트롤러까지 throws를 던졌다고 보면 된다.

이번에는 IOException이 TransactionAspectSupport.invokeWithinTransaction() 내부의 try-catch 블록에서 잡혔기 때문에 completeTransactionAfterThrowing()가 호출된다.

TransactionAspectSupport.invokeWithinTransaction()

그리고 @Transactional에 rollbackFor 설정을 하지 않았기 때문에, RuleBasedTransactionAttribute.rollbackRules에도 아무 롤백 규칙이 존재하지 않는다. 따라서 winner가 null이 되어 1. UncheckedException 발생 시 트랜잭션 동작과 동일하게 DefaultTransactionAttribute.rollBackOn()가 호출된다.

DefaultTransactionAttribute.rollBackOn()

다만 이번에는 넘어오는 예외가 RuntimeException이나 Error 타입이 아니기 때문에 rollbackOn() 메서드는 false를 반환하여 트랜잭션이 롤백되지 않고 커밋된다.

 

4. CheckedException 발생 시 트랜잭션 동작(rollbakFor 사용)

지금까지 내용을 잘 이해했다면, 별도로 try-catch로 잡는 순간 예외가 발생하더라도 TransactionAspectSupport.invokeWithinTransaction() 메서드의 catch 블록에서 예외가 감지되지 않기 때문에 completeTransactionAfterThrowing() 메서드도 호출되지 않으며, 이로 인해 트랜잭션은 정상적으로 커밋된다는 사실을 알 수 있을 것이다.

따라서 이번에는 throws로 예외를 처리하는 경우에 대해서만 살펴볼 것이다.

@Service
public class OrderService {

    @Autowired
    private OrderRepository orderRepository;

    @Transactional(rollbackFor = IOException.class) // rollbackFor 지정!
    public void processOrders(List<Order> orders) throws IOException {
        for (Order order : orders) {
            validateOrder(order);
            orderRepository.save(order);
        }
    }

    private void validateOrder(Order order) throws IOException {
        // 주문 설명이 없으면 IOException을 발생시킴 (Checked Exception)
        if (order.getDescription() == null || order.getDescription().isEmpty()) {
            throw new IOException("Order description cannot be empty"); // Checked Exception
        }
    }
}

위 코드에서는 @Transactional에서 rollbackFor 옵션을 사용해 IOException이 발생했을 때 트랜잭션을 롤백하도록 설정했다. (@Transactional에서는 rollbackFor이라는 필드로 Throwable의 모든 하위 예외 클래스들의 롤백을 유발하도록 정의할 수 있다. - https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/Transactional.html)

TransactionAspectSupport.invokeWithinTransaction()

마찬가지로 IOException이 invokeWithinTransaction() 메서드 내부 try-catch에 잡혔기 때문에 completeTransactionAfterThrowing()이 호출된다.

RuleBasedTransactionAttribute.rollbackOn()

다만 이번에는 @Transactional에 rollbackFor 설정했기 때문에 RuleBasedTransactionAttribute.rollbackRules 에는 IOException이 들어가게 된다. 따라서 winner가 null이 되지 않아 rollbackOn이 true로 반환되어 TransactionAspectSupport.completeTransactionAfterThrowing() 메서드 내부에서 롤백 로직을 수행하게 된다.

결론적으로 @Transactional(rollbackFor = IOException.class)을 사용하면 IOException을 throw 했을 때 롤백이 일어난다.

 

5. UncheckedException + noRollbackFor시 트랜잭션 동작

이번에는 rollbackFor이 아닌 noRollbackFor의 사용 시 동작 과정이다. 

@Service
public class OrderService {

    @Autowired
    private OrderRepository orderRepository;

    @Transactional(noRollbackFor = IllegalArgumentException.class) // noRollbackFor 지정!
    public void processOrders(List<Order> orders) {
        for (Order order : orders) {
            validateOrder(order);
            orderRepository.save(order);
        }
    }

    private void validateOrder(Order order) {
        // 주문 금액이 0보다 작으면 IllegalArgumentException 발생 (Unchecked Exception)
        if (order.getAmount() < 0) {
            throw new IllegalArgumentException("Order amount cannot be negative"); // Unchecked Exception
        }
    }
}

noRollbackFor이 없더라면 위 로직은 롤백되어야 할 것이다. 하지만 noRollbackFor 옵션을 사용하면 특정 UncheckedException이 발생하더라도 트랜잭션을 롤백하지 않고 커밋할 수 있도록 설정할 수 있다. 동작과정을 살펴보자.

TransactionAspectSupport.invokeWithinTransaction()

당연하게도 IllegalArgumentException이 TransactionAspectSupport.invokeWithinTransaction() 내부의 try-catch 블록에서 잡혔기 때문에 completeTransactionAfterThrowing()이 호출된다.

RuleBasedTransactionAttribute.rollbackOn()

@Override
public boolean rollbackOn(Throwable ex) {
    RollbackRuleAttribute winner = null; // 롤백 규칙을 결정할 변수
    int deepest = Integer.MAX_VALUE; // 계층 깊이를 추적하기 위한 변수

    if (this.rollbackRules != null) {
        for (RollbackRuleAttribute rule : this.rollbackRules) {
            // 예외가 롤백 규칙과 일치하는지 확인
            int depth = rule.getDepth(ex);
            // 예외의 깊이가 더 얕다면(계층적으로 더 가까운 규칙이라면) 해당 규칙을 winner로 설정
            if (depth >= 0 && depth < deepest) {
                deepest = depth;
                winner = rule;
            }
        }
    }

    // IllegalArgumentException에 대한 롤백 방지 규칙이 있으므로 winner가 NoRollbackRuleAttribute
    if (winner == null) {
        return super.rollbackOn(ex); // 기본적으로 RuntimeException과 Error일 때 롤백
    }

    return !(winner instanceof NoRollbackRuleAttribute); // NoRollbackRuleAttribute면 false 반환
}

RuleBasedTransactionAttribute.rollbackOn()

다만 원래라면 1. UncheckedException 발생 시 트랜잭션 동작처럼 winner가 null이 되어 rollbackOn()이 true로 반환되어 롤백이 일어나겠지만 이번에는 rollbackRules에 IllegalArgumentException에 대한 롤백 방지 규칙이 설정되어 있기 때문에 rollbackOn() 메서드는 false를 반환하여 롤백되지 않고 성공적으로 커밋된다.

결론적으로 @Transactional(noRollbackFor = RuntimeException.class)을 사용하면 RuntimeException이 발생하더라도 롤백이 일어나지 않고, 성공적으로 커밋된다.

 

 

정리

Java의 예외 종류와 Spring에서 @Transactional이 예외를 어떻게 처리하여 롤백하거나 커밋하는지에 대해 살펴보았다. 이 글은 총 2부로 나뉘며, 이번 1편에서는 트랜잭션과 예외 처리의 기본 개념과 동작 방식을 살펴보았다. 다음 2편에서는 서로 다른 클래스에서 트랜잭션을 호출할 때, Propagation.REQUIRES_NEW를 사용할 때 등을 예시로 들어 더 다양한 상황들을 예시를 들어, 해당 로직이 롤백될지 커밋될지 맞춰보는 방식으로 살펴볼 것이다.

위 내용의 전체적인 흐름은 https://sup2is.github.io/2021/03/04/java-exceptions-and-spring-transactional.html를 많이 참고했다.

다음 글(2편): https://dkswnkk.tistory.com/761