[Spring Boot] @Transactional의 7가지 전파 속성, 테스트를 통한 롤백 검증

1. 개요

매일 개발하며 사용해오던 @Transactional 어노테이션에 대해 아는게 너무 없다고 느꼈다. 여러 전파 전략, 옵션이 있다는거 정도만 알고있었지만, 깊게 고려해보진 않았던 것 같다. 

 

 

이참에 공부하고 제대로 알고 사용하고자 이 글을 작성한다.

 

 

 

 

 

 

 

 

 

 

2. 트랜잭션이란?

@Transactional 을 알아보기 앞서 트랜잭션에 대해 한번 더 짚고 넘어가자.

 

트랜잭션(Transaction)의 사전적 의미는 거래이고,

컴퓨터 과학 분야에서의 트랜잭션(Transaction)은 "더이상 분할이 불가능한 업무처리의 단위"를 의미한다.

 

 

이것은 하나의 작업을 위해 더이상 분할될 수 없는 명령들의 모음, 즉, 한꺼번에 수행되어야 할 일련의 연산모음을 의미한다. 

 

 

 

데이터베이스와 어플리케이션의 데이터 거래(Transaction)에 있어서 안전성을 확보하기 위한 방법이 트랜잭션인 것이다.

 

 

 

트랜잭션의 특징은 크게 4가지로 나뉜다.

• 원자성 (Atomicity)
• 일관성 (Consistency)
• 독립성 (Isolation)
• 지속성 (Durability)

 

원자성

1. 트랜잭션의 연산은 데이터베이스에 모두 반영되던지 아니면 모두 반영되지 않아야한다.

2. 트랜잭션 내의 모든 명령은 반드시 완벽히 수행되어야 하며, 하나라도 오류가 발생하면 트랜잭션 전부가 취소되어야 한다.

 

일관성

1. 트랜잭션을 성공적으로 완료하면 일관성 있는 데이터베이스 상태로 변환한다.

2. 시스템이 가지고 있는 고정요소는 트랜잭션 수행 전과 트랜잭션 수행 완료 후의 상태가 같아야 한다.

 

독립성

1. 둘 이상의 트랜잭션이 동시에 실행되는 경우 다른 트랜잭션의 연산이 끼어들 수 없다.

2. 수행중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없다.

 

지속성

1. 성공적으로 완료된 트랜잭션의 결과는 영구적으로 반영되어야 한다.

 

 

 

 

 

 

 

 

 

 

 

 

3. 스프링에서의 Transaction

스프링에서는 트랜잭션(Transaction)을 관리하기 위해 @Transactional 어노테이션을 제공한다. 

 

스프링의 트랜잭션은 프로그래밍 방식과 선언적 방식 두 가지로 사용할 수 있지만, 대부분의 경우 선언적 방식을 선호하고 @Transactional 이 이에 해당된다. 

 

클래스 또는 메서드 위에 @Transactional을 붙이면, 트랜잭션 기능이 적용된 프록시 객체가 생성되며, 트랜잭션 성공 여부에 따라 Commit 또는 Rollback 작업이 이루어진다.

 

 

 

 

스프링에서 트랜잭션을 관리하는 방법

Spring이 제공하는 @Transactional 의 장점 중 하나는 여러 트랜잭션을 묶어서 커다란 하나의 트랜잭션 경계를 만들 수 있다는 점이다.

 

 

개발을 하다 보면 트랜잭션 중에 새로운 트랜잭션을 만들어야 할 때도 있는데, 이때 어떻게 트랜잭션을 처리할 것인지에 대해 스프링은 여러 속성을 제공해준다. 이것이 전파 속성(Propagation)이다.

 

전파 속성에 따라 기존의 트랜잭션에 참여할 수도 있고, 별도의 트랜잭션으로 진행할 수도 있고, 에러를 발생시키는 등 여러 선택을 할 수 있다. 이렇게 하나의 트랜잭션이 다른 트랜잭션을 만나는 상황을 그림으로 나타내면 다음과 같다. 

 

 

이런 상황을 위해 이를 물리 트랜잭션과 논리 트랜잭션으로 나누어 처리한다. 

 

물리 트랜잭션은 실제 데이터베이스에 적용되는 트랜잭션으로, 커넥션을 통해 커밋/롤백하는 단위이고,

논리 트랜잭션은 스프링이 처리하는 트랜잭션 영역을 구분하기 위해 만들어진 개념이다.

 

 

예를 들어 다음의 그림은 외부 트랜잭션과 내부 트랜잭션이 1개의 물리 트랜잭션(커넥션)을 사용하는 경우이다.

 

 

기존의 트랜잭션이 진행중일 때 또 다른 트랜잭션이 사용되면 복잡한 상황이 발생한다. 스프링은 논리 트랜잭션이라는 개념을 도입함으로써 상황에 대한 설명을 쉽게 만들고, 다음과 같은 단순한 원칙을 세울수 있었다. 

 

 

1. 모든 논리 트랜잭션이 커밋되어야 물리 트랜잭션이 커밋됨 

2. 하나의 논리 트랜잭션이라도 롤백되면 물리 트랜잭션은 롤백됨

 

 

 

 

트랜잭션 전파 속성

 

스프링의 전파 속성에는 총 7가지가 있다.

 

 

 

1. REQUIRED

Defualt 속성이며, 모든 트랜잭션 매니저가 지원한다. 보통 이 속성으로 많이 사용한다. 미리 시작된 트랜잭션이 있으면 참여하고, 없으면 트랜잭션을 생성한다. 

 

부모 메서드와 자식 메서드가 하나의 트랜잭션으로 묶여 동작한다. 하나의 트랜잭션으로 묶이기 때문에 부모나 자식에서 예외가 발생하면 전체 트랜잭션이 롤백된다.

 

 

 

2. SUPPORTS

이미 시작된 트랜잭션이 있으면 참여하고 없으면 트랜잭션 없이 진행한다. 트랜잭션이 없긴 하지만 해당 경계 안에서 Connection이나 Hibernate Session 등을 공유할 수 있다.

 

 

 

3. MANDATORY

REQUIRED와 비슷하며, 이미 시작된 트랜잭션이 있으면 참여한다. 하지만 트랜잭션이 없다면 생성하는 것이 아니라 예외를 발생시킨다. 혼자서 독립적으로 트랜잭션을 실행하면 안되는 경우에 사용한다.

 

 

 

4. REQUIRED_NEW

항상 새로운 트랜잭션을 시작한다. 이미 진행 중인 트랜잭션이 있다면, 트랜잭션을 보류시킨다.

 

부모 트랜잭션과 자식 메서드의 트랜잭션이 완전히 분리되어 동작한다. 자식 메서드의 트랜잭션이 완료되면 부모 트랜잭션이 다시 활성화된다. 부모와 자식 트랜잭션이 서로 독립적이기 때문에 하나가 실패하더라도 다른 하나는 영향을 받지 않습니다.

 

 

 

5. NOT_SUPPORTED

트랜잭션을 사용하지 않게 한다. 이미 진행 중인 트랜잭션이 있으면 보류시킨다.

 

 

 

6. NEVER

트랜잭션을 사용하지 않도록 강제한다. 이미 진행 중인 트랜잭션도 존재하면 안되며, 트랜잭션이 있다면 예외를 발생시킨다.

 

 

 

7. NESTED

이미 진행 중인 트랜잭션이 있으면 중첩 트랜잭션을 시작한다. 중첩 트랜잭션은 말그대로 트랜잭션 안에 트랜잭션을 만드는 것이다.독립적인 트랜잭션을 만드는 REQUIRED_NEW와는 다르다.

 

중첩된 트랜잭션은 먼저 시작된 부모 트랜잭션의 커밋과 롤백에는 영향을 받지만, 자신의 커밋과 롤백은 부모 트랜잭션에게 영향을 주지 않는다. 이런 점에서 REQUIRED와도 다르다

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4. 테스트 코드로 검증

모든 전파 속성을 검증하진 않았고, 몇 가지 궁금한 속성들에 대해서만 테스트를 진행하였다.

 

 

1. REQUIERD - 자식에서 예외가 터질 때

// AService
@Transactional
public void saveWithRequiredFail(Member aMember, Member bMember) {
    memberRepository.save(aMember);
    // 예외 발생
    try {
        bService.saveMemberFail(bMember);
    } catch (RuntimeException e) {
        System.out.println("Required 트랜잭션 롤백 처리: " + e.getMessage());
    }
}


// BService
@Transactional
public void saveMemberFail(Member bMember) {
    memberRepository.save(bMember);
    throw new RuntimeException();
}


// Test Code
@Test
@DisplayName("[REQUIRED] 자식에서 예외가 터졌을 때")
public void saveWithRequiredFailTest() {
    Member aMember = new Member(1L);
    Member bMember = new Member(2L);

    assertThatThrownBy(() -> aService.saveWithRequiredFail(aMember, bMember))
        .isInstanceOf(RuntimeException.class);

    assertThat(memberRepository.findAll()).isEmpty();
}

 

자식 메서드에서 발생하는 예외를 try - catch로 잡았지만, 자식 트랜잭션에서 예외가 터지면서 부모까지 함께 롤백된다. 

 

 

 

 

 

 

2.1 MANDATORY - 트랜잭션 없이 자식 트랜잭션을 호출했을 때

// AService
public void saveWithMandatoryFail(Member aMember, Member bMember) {
    memberRepository.save(aMember);
    bService.saveMemberWithMandatory(bMember);
}


// BService
@Transactional(propagation = Propagation.MANDATORY)
public void saveMemberWithMandatory(Member bMember) {
    memberRepository.save(bMember);
}


// Test Code
@Test
@DisplayName("[MANDATORY] 부모가 트랜잭션이 없을 때")
public void saveWithMandatoryFailTest() {
    Member aMember = new Member(1L);
    Member bMember = new Member(2L);

    // 부모에서 트랜잭션 없이 실행
    assertThatThrownBy(() -> aService.saveWithMandatoryFail(aMember, bMember))
        .isInstanceOf(IllegalTransactionStateException.class);
}

 

트랜잭션 없이 MANDATORY 속성을 가진 하위 트랜잭션을 호출하면 IllegalTransactionStateException 예외가 발생한다.

 

 

 

2.2 MANDATORY - 트랜잭션 있이 자식 트랜잭션을 호출했을 때

// AService
@Transactional
public void saveWithMandatorySuccess(Member aMember, Member bMember) {
    memberRepository.save(aMember);
    bService.saveMemberWithMandatory(bMember);
}


// BService
@Transactional(propagation = Propagation.MANDATORY)
public void saveMemberWithMandatory(Member bMember) {
    memberRepository.save(bMember);
}


// Test Code
@Test
@DisplayName("[MANDATORY] 저장 성공 테스트")
public void saveWithMandatorySuccessTest() {
    Member aMember = new Member(1L);
    Member bMember = new Member(2L);

    aService.saveWithMandatorySuccess(aMember, bMember);

    assertThat(memberRepository.findAll()).size().isEqualTo(2);
}

 

트랜잭션을 달고 호출하면 예외 없이 잘 저장된다.

 

 

 

 

 

3. NOT SUPPORTED - 부모에서 예외가 터질 때 NOT SUPPORTED 속성을 가진 자식이 있을 때

// AService
@Transactional
public void saveWithNotSupported(Member aMember, Member bMember) {
    memberRepository.save(aMember);
    bService.saveWithNotSupported(bMember);
    throw new RuntimeException();
}


// BService
@Transactional(propagation = Propagation.NOT_SUPPORTED)
public void saveWithNotSupported(Member bMember) {
    memberRepository.save(bMember);
}


// Test Code
@Test
@DisplayName("[NOT SUPPORTED] 자식은 Not Supported 이고, 부모에서 예외가 발생할 때")
public void saveWithNotSupportedTest() {
    Member aMember = new Member(1L);
    Member bMember = new Member(2L);

    assertThatThrownBy(() -> aService.saveWithNotSupported(aMember, bMember))
        .isInstanceOf(RuntimeException.class);

    assertThat(memberRepository.findAll()).size().isEqualTo(1);
}

 

NOT SUPPORTED 속성은 부모의 트랜잭션을 보류시킨다고 되어있다. 트랜잭션이 Suspend된 상태이므로 자식은 트랜잭션의 영향을 받지 않게 되고, BService에서 저장한 BMember는 즉시 Database에 저장된다. 

 

만약 부모 트랜잭션에서 예외가 터지지 않았더라면 bMember 가 Database에 저장된 후 aMember가 저장됐을 것이다. 

 

 

 

 

 

 

 

4. NEVER - 부모가 트랜잭션이 있는데, 자식이 NEVER 속성을 가질 때

// AService
@Transactional
public void saveWithNeverFail(Member aMember, Member bMember) {
    memberRepository.save(aMember);
    bService.saveWithNeverFail(bMember);
}


// BService
@Transactional(propagation = Propagation.NEVER)
public void saveWithNeverFail(Member bMember) {
    memberRepository.save(bMember);
}


// Test Code
@Test
@DisplayName("[NEVER] 자식은 Never 이고, 부모가 트랜잭션이 있을 때")
public void saveWithNeverFailTest() {
    Member aMember = new Member(1L);
    Member bMember = new Member(2L);

    assertThatThrownBy(() -> aService.saveWithNeverFail(aMember, bMember))
        .isInstanceOf(IllegalTransactionStateException.class);
}

 

 

 

 

 

 

5.1 NESTED - 부모 트랜잭션의 롤백이 NESTED 속성을 가진 자식에게 전파될 때

// AService
@Transactional
public void saveWithNestedParentException(Member aMember, Member bMember) {
    memberRepository.save(aMember);
    bService.saveWithNestedParentException(bMember);
    throw new RuntimeException();
}


// BService
@Transactional(propagation = Propagation.NESTED)
public void saveWithNestedParentException(Member bMember) {
    memberRepository.save(bMember);
}


// Test Code
@Test
@DisplayName("[NESTED] 부모 트랜잭션의 롤백이 자식에게 전파")
public void saveWithNestedParentExceptionTest() {
    Member aMember = new Member(1L);
    Member bMember = new Member(2L);

    assertThatThrownBy(() -> aService.saveWithNestedParentException(aMember, bMember))
        .isInstanceOf(RuntimeException.class);

    assertThat(memberRepository.findAll()).size().isEqualTo(0);
}

 

자식 트랜잭션이 NESTED 속성을 가질 때 부모 트랜잭션에서 예외가 터지면 자식 트랜잭션도 함께 롤백된다. 

 

반대의 상황은 어떨까??

 

 

 

5.2 NESTED - NESTED 속성을 가진 자식 트랜잭션이 롤백될 때

// AService
@Transactional
public void saveWithNestedChildException(Member aMember, Member bMember) {
    memberRepository.save(aMember);
    try {
        bService.saveWithNestedChildException(bMember); // 중첩 트랜잭션
    } catch (RuntimeException e) {
        System.out.println("중첩 트랜잭션 롤백 처리: " + e.getMessage());
    }
}


// BService
@Transactional(propagation = Propagation.NESTED)
public void saveWithNestedChildException(Member bMember) {
    memberRepository.save(bMember);
    throw new RuntimeException();
}


// Test Code
@Test
@DisplayName("[NESTED] 자식 트랜잭션의 롤백이 부모에게 전파되지 않음")
public void saveWithNestedChildExceptionTest() {
    Member aMember = new Member(1L);
    Member bMember = new Member(2L);

    aService.saveWithNestedChildException(aMember, bMember);

    assertThat(memberRepository.findAll()).size().isEqualTo(1);
}

 

자식의 트랜잭션과는 무관하게 부모 트랜잭션에서 저장한 aMember는 커밋된다.