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

개요

이전 글에서는 Spring의 @Transactional 어노테이션이 기본적으로 어떻게 동작하는지, 그리고 예외 처리에 따라 트랜잭션이 롤백되는 메커니즘에 대해 다루었다. 이번 글에서는 실제 코드와 테스트를 통해 다양한 상황에서 트랜잭션이 어떻게 동작하는지 살펴볼 예정이다. 글을 읽는 분들도 각 상황에서 결과를 예측해 보며 따라가면 이해에 도움이 될 것 같다.

동일한 클래스 내에서의 트랜잭션 동작

• 본인 메서드에서 예외 발생 시 롤백
• 다른 메서드 호출 후 예외 발생 시 롤백
• 본인 메서드에서 try-catch로 예외 처리 후 커밋
• 다른 메서드 호출 후 본인 메서드에서 try-catch로 예외 처리 후 커밋
• 본인 메서드에서 noRollbackFor 설정 후 예외 발생 시 커밋
• noRollbackFor 설정된 다른 메서드 호출 시에도 상위 메서드의 트랜잭션 설정을 따라 롤백됨
• 동일 클래스 내에서 REQUIRES_NEW 설정된 메서드 호출 후 예외 발생 시 롤백됨
• noRollbackFor 설정 후 try-catch로 예외 처리 후 커밋

다른 클래스 간의 트랜잭션 동작

• ServiceA(에러) -> ServiceB의 REQUIRES_NEW 메서드 호출 시 부모 트랜잭션 롤백, 자식은 커밋
• ServiceA try-catch 예외처리 -> ServiceB(에러) 메서드 호출 시 롤백됨
• ServiceA -> ServiceB(에러)의 noRollbackFor 설정 메서드 호출 시 롤백
• ServiceA(noRollbackFor) -> ServiceB(에러) 메서드 호출
• ServiceA try-catch 예외처리 -> ServiceB(에러)의 noRollbackFor 설정 메서드 호출 시 커밋

바쁘신 분들은 위에 색을 넣은 세 가지 예시만이라도 꼭 살펴보았으면 좋겠다.

 

동일한 클래스 내에서의 트랜잭션 동작

1. 본인 메서드에서 예외 발생

@Service
public class ServiceA {
    @Transactional
    public void callOwnMethodWithException(Long memberId) {
        memberRepository.updateNameById(memberId, "Updated Name A1");
        throw new RuntimeException("Intentional Exception");
    }
}

@SpringBootTest
class TransactionTestApplicationTests {
    @Test
    @DisplayName("ServiceA: 본인 메서드에서 예외 발생 시 롤백")
    void testOwnMethodWithExceptionRollback() {
        assertThrows(RuntimeException.class, () -> serviceA.callOwnMethodWithException(1L));
        Member updatedMember = memberRepository.findById(1L).orElseThrow();
        assertEquals("Initial Name", updatedMember.getName());
    }
}

가장 기본적인 트랜잭션 롤백 사례다. @Transactionl이 적용된 메서드 내에서 RuntimeException이 발생하면 해당 트랜잭션은 롤백된다. 1편에서 살펴본 것처럼 @Transactional이 적용된 메서드가 호출되면 스프링은 내부적으로 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;
}

RuntimeException이 발생하면 catch 블록에서 completeTransactionAfterThrowing()이 호출되고, 이 메서드는 RuleBasedTransactionAttribute.rollbackOn()을 통해 롤백 여부를 결정하게 된다. 결국 RuntimeException과 같은 UncheckedException이 발생하므로 트랜잭션은 롤백되어 변경사항이 반영되지 않는다.

 

2. 다른 메서드 호출 후 예외 발생

@Service
public class ServiceA {
    @Transactional
    public void callAnotherMethodWithException(Long memberId) {
        callOwnMethodWithException(memberId);
    }

    @Transactional
    public void callOwnMethodWithException(Long memberId) {
        memberRepository.updateNameById(memberId, "Updated Name A1");
        throw new RuntimeException("Intentional Exception");
    }
}

@SpringBootTest
class TransactionTestApplicationTests {
    @Test
    @DisplayName("ServiceA: 다른 메서드 호출 후 예외 발생 시 롤백")
    void testAnotherMethodWithExceptionRollback() {
        assertThrows(RuntimeException.class, () -> serviceA.callAnotherMethodWithException(1L));
        Member updatedMember = memberRepository.findById(1L).orElseThrow();
        assertEquals("Initial Name", updatedMember.getName());
    }
}

이 경우도 동일하게 @Transactional이 적용된 메서드 내에서 RuntimeException이 발생하므로 트랜잭션이 롤백된다.

 

3. 본인 메서드에서 try-catch로 예외 처리

@Service
public class ServiceA {
    @Transactional
    public void callOwnMethodWithTryCatch(Long memberId) {
        try {
            memberRepository.updateNameById(memberId, "Updated Name A2");
            throw new RuntimeException("Intentional Exception");
        } catch (RuntimeException e) {
            // 예외를 처리하여 트랜잭션 롤백을 방지
        }
    }
}

@SpringBootTest
class TransactionTestApplicationTests {
    @Test
    @DisplayName("ServiceA: 본인 메서드에서 try-catch로 예외 처리 후 커밋")
    void testOwnMethodWithTryCatchCommit() {
        serviceA.callOwnMethodWithTryCatch(1L);
        Member updatedMember = memberRepository.findById(1L).orElseThrow();
        assertEquals("Updated Name A2", updatedMember.getName());
    }
}

@Transactional이 적용된 메서드에서 예외가 발생해도 try-catch로 예외를 처리하면 트랜잭션은 롤백되지 않고 커밋된다. 1편에서 다뤘듯이 Spring의 트랜잭션 관리 메커니즘 때문인데, 내부적으로 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;
    }
    // 비즈니스 로직이 정상적으로 완료되면 커밋 수행
    commitTransactionAfterReturning(txInfo);
    return retVal;
}

따라서 RuntimeException이 발생하면 try 블록 내에서 예외가 발생하더라도 catch 블록에서 예외를 처리하면 invokeWithinTransaction() 메서드의 catch 블록에 도달하지 않기 때문에 Spring은 비즈니스 로직이 정상적으로 완료된 것으로 판단하고 트랜잭션을 커밋한다.

 

4. 다른 메서드 호출 후 try-catch로 예외 처리

@Service
public class ServiceA {
    @Transactional
    public void callAnotherMethodWithTryCatch(Long memberId) {
        try {
            callOwnMethodWithException(memberId);
        } catch (RuntimeException e) {
            // 예외 처리로 트랜잭션 롤백 방지
        }
    }

    @Transactional
    public void callOwnMethodWithException(Long memberId) {
        memberRepository.updateNameById(memberId, "Updated Name A1");
        throw new RuntimeException("Intentional Exception");
    }
}

@SpringBootTest
class TransactionTestApplicationTests {
    @Test
    @DisplayName("ServiceA: 다른 메서드 호출 후 try-catch로 예외 처리 후 커밋")
    void testAnotherMethodWithTryCatchCommit() {
        serviceA.callAnotherMethodWithTryCatch(1L);
        Member updatedMember = memberRepository.findById(1L).orElseThrow();
        assertEquals("Updated Name A1", updatedMember.getName());
    }
}

이 경우도 마찬가지로 예외가 try-catch로 처리되어 트랜잭션이 커밋된다. callOwnMethodWithException에서 발생한 RuntimeException이 callAnotherMethodWithTryCatch의 try-catch 블록에서 처리되므로, 트랜잭션이 정상적으로 커밋되어 "Updated Name A1"로의 변경이 유지된다.

 

5. 본인 메서드에서 noRollbackFor 설정 후 예외 발생

@Service
public class ServiceA {
    @Transactional(noRollbackFor = RuntimeException.class)
    public void callOwnMethodWithNoRollback(Long memberId) {
        memberRepository.updateNameById(memberId, "Updated Name A3");
        throw new RuntimeException("Intentional Exception");
    }
}

@SpringBootTest
class TransactionTestApplicationTests {
    @Test
    @DisplayName("ServiceA: 본인 메서드에서 noRollbackFor 설정 후 예외 발생 시 커밋")
    void testOwnMethodWithNoRollbackCommit() {
        assertThrows(RuntimeException.class, () -> serviceA.callOwnMethodWithNoRollback(1L));
        Member updatedMember = memberRepository.findById(1L).orElseThrow();
        assertEquals("Updated Name A3", updatedMember.getName());
    }
}

1편에서 살펴본 것처럼, noRollbackFor 설정을 사용하면 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) {
                deepest = depth;
                winner = rule;
            }
        }
    }

    // noRollbackFor 설정으로 인해 winner가 NoRollbackRuleAttribute 인스턴스가 됨
    if (winner == null) {
        return super.rollbackOn(ex);  // 부모 클래스의 rollbackOn 호출
    }

    // NoRollbackRuleAttribute 인스턴스라면 롤백하지 않음
    return !(winner instanceof NoRollbackRuleAttribute);
}

따라서 RuntimeException이 발생하더라도 noRollbackFor 설정에 의해 롤백되지 않고 변경사항이 커밋된다.

 

6. noRollbackFor 설정된 다른 메서드 호출 후 예외 발생

@Service
public class ServiceA {
    @Transactional
    public void callAnotherMethodWithNoRollback(Long memberId) {
        callOwnMethodWithNoRollback(memberId);
    }

    @Transactional(noRollbackFor = RuntimeException.class)
    public void callOwnMethodWithNoRollback(Long memberId) {
        memberRepository.updateNameById(memberId, "Updated Name A3");
        throw new RuntimeException("Intentional Exception");
    }
}

@SpringBootTest
class TransactionTestApplicationTests {
    @Test
    @DisplayName("ServiceA: noRollbackFor 설정된 다른 메서드 호출 시에도 상위 메서드의 트랜잭션 설정을 따라 롤백됨")
    void testAnotherMethodWithNoRollbackCommit() {
        assertThrows(RuntimeException.class, () -> serviceA.callAnotherMethodWithNoRollback(1L));
        Member updatedMember = memberRepository.findById(1L).orElseThrow();
        assertEquals("Initial Name", updatedMember.getName());
    }
}

호출하는 메서드(callAnotherMethodWithNoRollback)에는 일반적인 @Transactional이 적용되어 있고 호출되는 메서드(callOwnMethodWithNoRollback)에는 noRollbackFor가 설정되어 있다. 즉 RuntimeException이 발생해도 트랜잭션 롤백이 되지 않도록 설정된 상태이다.

그러나 여기서 주의할 점은 Spring의 트랜잭션 관리 방식이 프록시 기반이라는 점이다. 스프링은 트랜잭션 처리를 위해 AOP방식을 사용하며, 트랜잭션이 적용된 메서드를 호출할 때 프록시 객체가 트랜잭션 경계를 관리한다. 하지만 동일 클래스 내에서 호출된 메서드는 프록시를 거치지 않고 실제 객체의 메서드를 직접 호출하게 된다. 이로 인해 callOwnMethodWithNoRollback에서 설정된 @Transactional 및 noRollbackFor는 무시된다. 그렇기에 예외가 발생해도 외부 메서드(callAnotherMethodWithNoRollback)의 @Transactional 설정만 적용되어 트랜잭션이 롤백된다.

 

7. 동일 클래스 내에서 REQUIRES_NEW 설정된 메서드 호출 후 예외 발생

@Service
public class ServiceA {
    @Transactional
    public void callMethodWithTransaction(Long memberId) {
        callRequiresNewInSameClassMethod(memberId);
        throw new RuntimeException("Intentional Exception with REQUIRES_NEW");
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void callRequiresNewInSameClassMethod(Long memberId) {
        memberRepository.updateNameById(memberId, "Updated Name A4");
    }
}

@SpringBootTest
class TransactionTestApplicationTests {
    @Test
    @DisplayName("ServiceA: 동일 클래스 내에서 REQUIRES_NEW 설정된 메서드 호출 후 예외 발생 시 롤백됨")
    void testRequiresNewInSameClassMethod() {
        assertThrows(RuntimeException.class, () -> serviceA.callMethodWithTransaction(1L));
        Member updatedMember = memberRepository.findById(1L).orElseThrow();
        assertEquals("Initial Name", updatedMember.getName());
    }
}

REQUIRES_NEW 전파 속성을 사용하면 기존의 트랜잭션과 관계없이 새로운 트랜잭션을 생성하여 실행되도록 한다. 하지만 이전에 말한 것과 같이 스프링은 AOP를 사용하여 트랜잭션 경계를 관리하기 때문에, 같은 클래스 내에서 메서드를 호출하면 프록시가 적용되지 않아 전파 속성이 제대로 적용되지 않는다.

따라서 callRequiresNewInSameClassMethod 메서드에서 REQUIRES_NEW를 설정하였음에도 불구하고, 내부에서 callRequiresNewInSameClassMethod를 호출할 때 프록시가 적용되지 않아 새로운 트랜잭션이 생성되지 않고 기존 트랜잭션이 그대로 유지되며 RuntimeException이 발생하면 기존 트랜잭션이 롤백된다.

 

8. noRollbackFor설정 후 try-catch로 예외 처리

@Service
public class ServiceA {
    @Transactional(noRollbackFor = RuntimeException.class)
    public void callMethodWithNoRollbackAndTryCatch(Long memberId) {
        try {
            memberRepository.updateNameById(memberId, "Updated Name A5");
            throw new RuntimeException("Intentional Exception");
        } catch (RuntimeException e) {
            // Exception handled
        }
    }
}

@SpringBootTest
class TransactionTestApplicationTests {
    @Test
    @DisplayName("ServiceA: noRollbackFor 설정 후 try-catch로 예외 처리 후 커밋")
    void testNoRollbackForWithTryCatch() {
        serviceA.callMethodWithNoRollbackAndTryCatch(1L);
        Member updatedMember = memberRepository.findById(1L).orElseThrow();
        assertEquals("Updated Name A5", updatedMember.getName());
    }
}

이 경우는 두 가지 메커니즘이 동시에 적용된다.

1. noRollbackFor 설정으로 RuntimeException에 대한 롤백 방지
2. try-catch로 인한 예외의 메서드 밖 전파 방지

둘 중 어느 하나만 적용되어도 트랜잭션이 커밋되는데, 두 가지가 모두 적용되어 있으므로 당연히 변경사항이 정상적으로 커밋된다.

 

 

다른 클래스 간의 트랜잭션 동작

1. ServiceA(에러) -> ServiceB의 REQUIRES_NEW 메서드 호출

@Service
public class ServiceA {
    @Transactional
    public void callRequiresNewInOtherMethod(Long memberId) {
        serviceB.updateNameInNewTransaction(memberId, "Updated Name B1");
        memberRepository.updateNameById(memberId, "Updated Name A1");
        
        throw new RuntimeException("Intentional Exception");
    }
}

@Service
public class ServiceB {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void updateNameInNewTransaction(Long memberId, String newName) {
        memberRepository.updateNameById(memberId, newName);
    }
}

@SpringBootTest
class TransactionTestApplicationTests {
    @Test
    @DisplayName("ServiceA(에러) -> ServiceB의 REQUIRES_NEW 메서드 호출 시 부모 트랜잭션 롤백, 자식은 커밋")
    void testRequiresNewMethodWithRollback() {
        assertThrows(RuntimeException.class, () -> serviceA.callRequiresNewInOtherMethod(1L));
        Member updatedMember = memberRepository.findById(1L).orElseThrow();
        assertEquals("Updated Name B1", updatedMember.getName());
    }
}

ServiceB의 메서드에 REQUIRES_NEW를 사용했으므로, ServiceA의 트랜잭션과는 독립적인 새로운 트랜잭션이 생성된다.

1. ServiceB의 트랜잭션이 먼저 실행되어 "Updated Name B1"로 업데이트 및 커밋된다.
2. 이후 ServiceA에서도 "Updated Name A1"으로 업데이트하지만 RuntimeException이 발생하여 ServiceA의 트랜잭션은 롤백된다.
3. 하지만 ServiceB의 트랜잭션은 이미 커밋되었고 독립적이므로, "Updated Name B1"이 유지된다.

REQUIRES_NEW는 항상 새로운 트랜잭션을 생성하고, 이 트랜잭션은 호출한 곳의 트랜잭션과 완전히 독립적으로 동작한다. 따라서 부모 트랜잭션(ServiceA)에서 문제가 발생하더라도 자식 트랜잭션(ServiceB)의 변경사항은 영향을 받지 않고 유지된다.

 

2. ServiceA try-catch 예외처리 -> ServiceB(에러) 메서드 호출

@Service
public class ServiceA {
    @Transactional
    public void callMethodInServiceBWithTryCatch(Long memberId, String newName) {
        try {
            serviceB.updateNameWithException(memberId, newName);
        } catch (RuntimeException e) {
            // Exception handled
        }
    }
}

@Service
public class ServiceB {
    @Transactional
    public void updateNameWithException(Long memberId, String newName) {
        memberRepository.updateNameById(memberId, newName);
        throw new RuntimeException("Intentional Exception");
    }
}

@SpringBootTest
class TransactionTestApplicationTests {
    @Test
    @DisplayName("ServiceA try-catch 예외처리 -> ServiceB(에러) 메서드 호출 시 롤백됨")
    void testTryCatchCommitInServiceB() {
        serviceA.callMethodInServiceBWithTryCatch(1L, "Updated Name B2");
        Member updatedMember = memberRepository.findById(1L).orElseThrow();
        assertEquals("Updated Name B2", updatedMember.getName());
    }
}

이번 게시글에서 어려운 케이스 중 첫번째이다. try-catch로 예외를 처리했음에도 불구하고 왜 rollback-only 발생하고, 결국 트랜잭션이 롤백되는지 이해하기 쉽지 않았다. 트랜잭션이 어떻게 처리되는지 단계별로 살펴보자.

1. ServiceA의 트랜잭션 시작

• @Transactional이 적용된 ServiceA의 메서드가 호출되면서 새로운 트랜잭션이 생성

2. ServiceB의 메서드가 호출되면서 트랜잭션에 참여

• ServiceB의 @Transactional은 기본값인 REQUIRED를 사용하여 새로운 트랜잭션을 생성하지 않고, 이미 존재하는 ServiceA의 트랜잭션에 참여

3. ServiceB에서 RuntimeException 발생

• 이때 스프링은 내부적으로 TransactionAspectSupport.completeTransactionAfterThrowing() 실행
• 여기서 해당 트랜잭션을 "rollback-only"로 마킹하고 롤백이 발생

protected void completeTransactionAfterThrowing(@Nullable TransactionInfo txInfo, Throwable ex) {
    if (txInfo.transactionAttribute.rollbackOn(ex)) {
        txInfo.getTransactionManager().rollback(txInfo.getTransactionStatus());
    }
}

4. ServiceA에서 예외를 catch로 잡음

• 예외는 정상적으로 catch 되어 처리되지만 이미 트랜잭션은 "rollback-only"로 마킹된 상태

5. 트랜잭션 커밋 시도

• ServiceA의 메서드가 종료되면서 트랜잭션 커밋이 시도되지만, "rollback-only" 상태로 마킹된 트랜잭션은 커밋이 불가능
• 결과적으로 UnexpectedRollbackException이 발생하고 트랜잭션이 롤백됨

정리하면 ServiceB에서 예외가 발생하면 트랜잭션은 TransactionAspectSupport.completeTransactionAfterThrowing()에 의해 "rollback-only" 상태로 마킹된다. 이 상태에서 ServiceA에서 예외를 try-catch로 처리하더라도 이미 롤백 상태로 마킹된 트랜잭션은 커밋될 수 없고, 결국 UnexpectedRollbackException이 발생하며 트랜잭션이 롤백된다. 더 자세한 내용은 우아한형제들 기술 블로그에서 다룬 내용을 참고하면 도움이 될 것 같다.

 

3. ServiceA -> ServiceB(에러)의 noRollbackFor 설정 메서드 호출

@Service
public class ServiceA {
    @Transactional
    public void callMethodInServiceBWithNoRollback(Long memberId, String newName) {
        serviceB.updateNameWithNoRollback(memberId, newName);
    }
}

@Service
public class ServiceB {
    @Transactional(noRollbackFor = RuntimeException.class)
    public void updateNameWithNoRollback(Long memberId, String newName) {
        memberRepository.updateNameById(memberId, newName);
        throw new RuntimeException("Intentional Exception");
    }
}

@SpringBootTest
class TransactionTestApplicationTests {
    @Test
    @DisplayName("ServiceA -> ServiceB(에러)의 noRollbackFor 설정 메서드 호출 시 롤백")
    void testNoRollbackForCommitInServiceB() {
        assertThrows(RuntimeException.class, () -> serviceA.callMethodInServiceBWithNoRollback(1L, "Updated Name B3"));
        Member updatedMember = memberRepository.findById(1L).orElseThrow();
        assertEquals("Initial Name", updatedMember.getName());
    }
}

이번 게시글에서 어려운 케이스 중 두 번째이다. 이 케이스는 처음에 ServiceB의 메서드에 noRollbackFor를 설정했으니 롤백이 일어나지 않을 것이라 생각했으나 실제로는 롤백이 발생하여 "Initial Name"이 유지되었다.

이와 같이 noRollbackFor 설정이 예상대로 동작하지 않는 이유는 noRollbackFor 설정은 해당 메서드나 클래스에서 직접 발생한 예외에 대해서만 적용되기 때문이다. ServiceA에서 호출되는 ServiceB의 메서드는 noRollbackFor로 설정했지만 설정은 ServiceB의 트랜잭션 내에서만 적용되고, ServiceA의 트랜잭션에서는 여전히 RuntimeException을 처리하기 위해 롤백이 발생할 수 있는 상황이다. 따라서 ServiceB에서 RuntimeException이 발생한 후 부모 트랜잭션인 ServiceA에서 롤백이 일어나게 된다.

 

4. ServiceA(noRollbackFor) -> ServiceB(에러) 메서드 호출

그렇다면 이번에는 반대로 호출하는 쪽에서 noRollbackFor가 걸려있다면 어떻게 될까?

@Service
public class ServiceA {
    @Transactional(noRollbackFor = RuntimeException.class)
    public void callNoRollbackInServiceAWithExceptionInServiceB(Long memberId, String newName) {
        serviceB.updateNameWithException(memberId, newName);
    }
}

@Service
public class ServiceB {
    @Transactional
    public void updateNameWithException(Long memberId, String newName) {
        memberRepository.updateNameById(memberId, newName);
        throw new RuntimeException("Intentional Exception in ServiceB");
    }
}

@SpringBootTest
class TransactionTestApplicationTests {
    @Test
    @DisplayName("ServiceA(noRollbackFor) -> ServiceB(에러) 메서드 호출 시 롤백")
    void testNoRollbackInServiceAWithExceptionInServiceB() {
        assertThrows(RuntimeException.class, () -> 
            serviceA.callNoRollbackInServiceAWithExceptionInServiceB(1L, "Updated Name A6"));
        Member updatedMember = memberRepository.findById(1L).orElseThrow();
        assertEquals("Initial Name", updatedMember.getName());
    }
}

3번에서 봤듯이 noRollbackFor 설정은 해당 메서드나 클래스에서 직접 발생한 예외에 대해서만 적용되기 때문에 ServiceB에서 발생한 예외에 대해서는 ServiceA의 noRollbackFor 설정이 영향을 미치지 않아 롤백이 일어난다.

 

5. ServiceA try-catch 예외처리 -> ServiceB(에러)의 noRollbackFor 설정 메서드 호출

@Service
public class ServiceA {
    @Transactional
    public void callMethodInServiceBWithNoRollbackAndTryCatch(Long memberId, String newName) {
        try {
            serviceB.updateNameWithNoRollback(memberId, newName);
        } catch (RuntimeException e) {
            // Exception handled
        }
    }
}

@Service
public class ServiceB {
    @Transactional(noRollbackFor = RuntimeException.class)
    public void updateNameWithNoRollback(Long memberId, String newName) {
        memberRepository.updateNameById(memberId, newName);
        throw new RuntimeException("Intentional Exception");
    }
}

@SpringBootTest
class TransactionTestApplicationTests {
    @Test
    @DisplayName("ServiceA try-catch 예외처리 -> ServiceB(에러)의 noRollbackFor 설정 메셔드 호출 시 커밋")
    void testNoRollbackForWithTryCatchInServiceB() {
        serviceA.callMethodInServiceBWithNoRollbackAndTryCatch(1L, "Updated Name B6");
        Member updatedMember = memberRepository.findById(1L).orElseThrow();
        assertEquals("Updated Name B6", updatedMember.getName());
    }
}

내 기준에서는 처음에 가장 이해하기 어려운 케이스였다. 2번 케이스에서는 RuntimeException 발생 시 트랜잭션이 즉시 "rollback-only"로 마킹되었기 때문에 ServiceA의 try-catch로 예외를 잡더라도 이미 롤백이 예약된 상태라 결국 롤백되었다. 그리고 3번 케이스에서는 ServiceB의 noRollbackFor 설정이 있었지만, 예외가 ServiceA까지 전파되어 결국 롤백되었다. 

그리고 이번 케이스는 2번과 3번 케이스를 전부 동시에 만족하는 상황이라 당연히 롤백이 일어날 것으로 예상했으나 실제로는 커밋이 이루어졌다. 그 이유는 다음과 같다.

1. ServiceB의 noRollbackFor 설정으로 RuntimeException 발생 시 "rollback-only" 마킹이 되지 않음
2. ServiceA의 try-catch로 예외가 상위로 전파되는 것을 방지

즉 ServiceB에서 예외가 발생해도 noRollbackFor 설정으로 인해 롤백 마킹이 되지 않고, 롤백 마킹이 없는 상태에서 ServiceA의 try-catch가 예외를 정상적으로  처리하여 트랜잭션이 정상적으로 커밋되게 된다.

 

 

정리

1편에서는 Spring의 @Transactional 어노테이션의 기본적인 동작과 예외 처리에 따른 롤백 메커니즘에 대해 살펴보았고, 2편에서는 실제 테스트 코드를 통해 다양한 상황에서의 트랜잭션 동작을 알아보았다. 동일 클래스 내 트랜잭션 동작에 대해서는 어느 정도 예상한 대로 동작했지만, 다른 클래스 간 트랜잭션 동작에서는 try-catch와 noRollbackFor 설정의 조합에 따라 트랜잭션의 롤백 여부가 결정되는 예상치 못한 경우들이 많이 발생했다.

마지막으로.. 이런 이론을 알아두는 것도 물론 좋지만 본질적으로 트랜잭션 내에서 RuntimeException을 catch 하려 했던 시도 자체가 올바른 것이었을까? 생각해 보는 것도 좋을 것 같다.