[스프링 DB 2편] #11. 스프링 트랜잭션 전파2 - 활용

[YONGHYNG]

트랜잭션 전파 활용1 - 예제 프로젝트 시작

비즈니스 요구사항

• 회원을 등록하고 조회
• 회원에 대한 변경 이ㅣ력을 추적할 수 있도록 회원 데이터가 변경될 떄 변경 이력을 DB LOG 테이블에 남김

Member

• JPA를 통해 관리하는 회원 엔티티

import lombok.Getter;
import lombok.Setter;

import javax.persistence.*;

@Entity
@Getter
@Setter
public class Member {

    @Id
    @GeneratedValue
    private Long id;
    private String username;

    public Member(String username) {
        this.username = username;
    }
}

MemberRepository

• JPA를 사용하는 회원 리포지토리, 저장과 조회 기능 제공

package hello.springtx.propagation; // 패키지 선언

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j; 
import org.springframework.stereotype.Repository; 
import org.springframework.transaction.annotation.Transactional; 
import javax.persistence.EntityManager; 
import java.util.Optional; 

@Slf4j // 로그 객체를 자동으로 생성해주는 Lombok 어노테이션
@Repository // 이 클래스가 데이터 접근 계층(DAO)임을 나타냄
@RequiredArgsConstructor // final 필드에 대해 생성자를 자동으로 생성해주는 Lombok 어노테이션
public class MemberRepository {

    private final EntityManager em; // JPA의 EntityManager로 데이터베이스 작업을 처리

    /**
     * 회원 정보를 데이터베이스에 저장하는 메서드
     * @param member 저장할 회원 객체
     */
    @Transactional // 메서드를 트랜잭션 안에서 실행하도록 설정
    public void save(Member member) {
        log.info("member 저장"); // 로그 출력
        em.persist(member); // JPA를 통해 회원 정보를 영속성 컨텍스트에 저장
    }

    /**
     * username으로 회원 정보를 조회하는 메서드
     * @param username 조회할 회원의 사용자 이름
     * @return 조회된 회원 정보(Optional로 반환)
     */
    public Optional<Member> find(String username) {
        // JPQL을 사용하여 username으로 회원 정보를 조회
        return em.createQuery("select m from Member m where m.username=:username", Member.class) 
                 .setParameter("username", username) // JPQL의 파라미터 바인딩
                 .getResultList() // 결과를 리스트로 반환
                 .stream() // 스트림 변환
                 .findAny(); // 첫 번째 결과를 Optional로 반환
    }
}

Log

• JPA를 통해 관리하는 로그 엔티티

import lombok.Getter;
import lombok.Setter;

@Entity
@Getter
@Setter
public class Log {

    @Id
    @GeneratedValue
    private Long id;
    private String message;

    public Log(){}

    public Log(String message){
        this.message = message;
    }
}

LogRepository

• JPA를 사용하는 로그 리포지토리, 저장과 조회 기능 제공
• 중간에 예외 상황을 재현하기 위해 로그예외라고 입력하는 경우 예외 발생

package hello.springtx.propagation; 

import lombok.RequiredArgsConstructor; 
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Repository; 
import org.springframework.transaction.annotation.Transactional; 
import javax.persistence.EntityManager; 
import java.util.Optional;

@Slf4j // 로그 객체를 생성
@Repository // 데이터 접근 계층(DAO)을 나타냄
@RequiredArgsConstructor // final 필드의 생성자를 자동 생성
public class LogRepository {

    private final EntityManager em; // JPA의 EntityManager로 데이터베이스 작업 수행

    /**
     * 로그 메시지를 데이터베이스에 저장하는 메서드
     * @param logMessage 저장할 로그 객체
     */
    @Transactional // 트랜잭션을 처리
    public void save(Log logMessage) {
        log.info("log 저장"); // 로그 출력
        em.persist(logMessage); // 로그 데이터를 영속성 컨텍스트에 저장
        if (logMessage.getMessage().contains("로그예외")) { // 특정 문자열 포함 여부 확인
            log.info("log 저장시 예외 발생"); // 예외 발생 전 로그 출력
            throw new RuntimeException("예외 발생"); // 강제로 예외 발생
        }
    }

    /**
     * 메시지를 기준으로 로그 데이터를 조회하는 메서드
     * @param message 조회할 메시지
     * @return 조회된 로그(Optional로 반환)
     */
    public Optional<Log> find(String message) {
        return em.createQuery("select l from Log l where l.message = :message", Log.class) // JPQL 실행
                 .setParameter("message", message) // 파라미터 바인딩
                 .getResultList() // 결과 리스트 반환
                 .stream() // 스트림 변환
                 .findAny(); // 첫 번째 결과를 Optional로 반환
    }
}

MemberService

• 회원을 등록하면 동시에 회원 등록에 대한 DB 로그도 함께 남김

JoinV1()

• 회원과 DB로그를 함께 남기는 비즈니스 로직
• 현재 별도의 트랜 잭션은 설정하지 않음

JoinV2()

• joinV1()과 같은 기능을 수행
• DB로그 저장시 예외가 발생하면 예외 복구
• 별도의 트랜잭션 저장하지 않음

package hello.springtx.propagation;

import lombok.RequiredArgsConstructor; 
import lombok.extern.slf4j.Slf4j; 
import org.springframework.stereotype.Service; 

@Slf4j // 로그 객체 생성
@Service // 서비스 계층을 나타냄
@RequiredArgsConstructor // final 필드의 생성자를 자동 생성
public class MemberService {

    private final MemberRepository memberRepository; // Member 저장소
    private final LogRepository logRepository; // Log 저장소

    /**
     * 회원과 로그를 저장하는 메서드 - 예외 발생 시 트랜잭션 롤백
     * @param username 저장할 회원 이름
     */
    public void joinV1(String username) {
        Member member = new Member(username); // Member 객체 생성
        Log logMessage = new Log(username); // Log 객체 생성
        
        log.info("== memberRepository 호출 시작 ==");
        memberRepository.save(member); // Member 저장
        log.info("== memberRepository 호출 종료 ==");
        
        log.info("== logRepository 호출 시작 ==");
        logRepository.save(logMessage); // Log 저장
        log.info("== logRepository 호출 종료 ==");
    }

    /**
     * 회원과 로그를 저장하는 메서드 - 로그 저장 중 예외를 처리
     * @param username 저장할 회원 이름
     */
    public void joinV2(String username) {
        Member member = new Member(username); // Member 객체 생성
        Log logMessage = new Log(username); // Log 객체 생성
        
        log.info("== memberRepository 호출 시작 ==");
        memberRepository.save(member); // Member 저장
        log.info("== memberRepository 호출 종료 ==");
        
        log.info("== logRepository 호출 시작 ==");
        try {
            logRepository.save(logMessage); // Log 저장
        } catch (RuntimeException e) {
            log.info("log 저장에 실패했습니다. logMessage={}", logMessage.getMessage()); // 실패 로그 출력
            log.info("정상 흐름 변환"); // 예외를 정상 흐름으로 변환
        }
        log.info("== logRepository 호출 종료 ==");
    }
}

테스트 코드

package hello.springtx.propagation;

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 static org.assertj.core.api.Assertions.assertThatThrownBy;
import static org.junit.jupiter.api.Assertions.assertTrue;

@Slf4j
@SpringBootTest
class MemberServiceTest {

    @Autowired
    MemberService memberService;
    @Autowired
    MemberRepository memberRepository;
    @Autowired
    LogRepository logRepository;

    /**
     * MemberService @Transactional:OFF
     * MemberRepository @Transactional:ON
     * LogRepository @Transactional:ON
     */
    @Test
    void outerTxOff_success() {
        // given
        String username = "outerTxOff_success";

        // when
        memberService.joinV1(username);

        // then: 모든 데이터가 정상 저장된다.
        assertTrue(memberRepository.find(username).isPresent());
        assertTrue(logRepository.find(username).isPresent());
    }
}

참고

• JPA의 구현체인 하이버네이트가 테이블을 자동 생성
• 메모리 DB이기 떄문에 모든 테스트가 완료된 이후 테이블 삭제
• 여기서 각각의 테스트가 완료된 시점에 데이터를 삭제하지 않음, 따라서 username은 테스트별로 각각 다르게 설정, 그렇지 않으면 다음 테스트에 영향을 줌, 모든 테스트가 완료되어야 DB가 사라짐

JPA와 데이터 변경

• JPA를 통한 모든 데이터 변경(등록, 수정, 삭제)는 트랜잭션 필요, 조회는 필요 없음
• 현재 코드에서 서비스 계층에 트랜잭션이 없기 떄문에 리포지토리에 트랜잭션이 있음

트랜잭션 전파 활용2 - 커밋, 롤백

서비스 계층에 트랜잭션이 없을 때 - 커밋

상황

• 서비스 계층에 트랜잭션이 없음
• 회원, 로그 리포지토리가 각각 트랜잭션을 가지고 있음
• 회원, 로그 리포지토리 둘 다 커밋 성공

outerTxOff_success

/**
 * MemberService @Transactional:OFF
 * MemberRepository @Transactional:ON
 * LogRepository @Transactional:ON
 */
@Test
void outerTxOff_success() {
           //given
           String username = "outerTxOff_success";
           //when
           memberService.joinV1(username);
           //then: 모든 데이터가 정상 저장된다.
           assertTrue(memberRepository.find(username).isPresent());
           assertTrue(logRepository.find(username).isPresent());
}

1. MemberService에서 MemberRepository를 호출, MemberRepository에는 @transactional 애노테이션이 있으므로 트랜잭션 AOP가 작동, 여기서 트랜잭션 매니저를 통해 트랜잭션을 시작(여기서 시작한 트랜잭션을 트랜잭션 B라 함)

1-1. 그림에서는 생략했지만, 트랜잭션 매니저에 트랜잭션을 요청하면 데이터소스를 통해 커넥션 con1을 획득하고, 해당 커넥션을 수동 커밋 모드로 변경해서 트랜잭션을 시작

1-2. 트랜잭션 동기화 매니저를 통해 트랜잭션을 시작한 커넥션을 보관

1-3. 트랜잭션 매니저의 호출 결과로 status를 반환, 여기서는 신규 트랜잭션 여부가 참이 됨

2. MemberRepository는 JPA를 통해 회원을 저장하는데, 이때 JPA는 트랜잭션이 시작된 con1을 사용해서 회원을 저장

3. MemberRepository가 정상 응답을 반환했기 떄문에 AOP는 트랜잭션 매니저에 커밋을 요청

4. 트랜잭션 매니저는 con1을 통해 물리 트랜잭션을 커밋

4-1. 이 시점에 앞서 설명한 신규 트랜잭션 여부, rollbackOnly 여부 모두 체크

• MemberRepository와 관련된 모든 데이터는 정상 커밋 됨, 트랜잭션 B는 완전 종료 됨
• 이후 LogRepository를 통해 트랜잭션C를 시작하고 , 정상 커밋 함
• 결과적으로 둘다 커밋되어 Member, Log 모두 안전하게 저장 됨

@transactional과 REQUIRED

• 트랜잭션 전파의 기본 값은 REQUIRED, 따라서 아래 둘은 같음
• @transactional(propagation = Propagation.REQUIRED)
• @transactional
• REQUIRED는 기존 트랜잭션이 없으면 새로운 트랜잭션을 만들고, 기존 트랜잭션이 있으면 참여

서비스 계층에 트랜잭션이 없을 때 - 롤백

상황

• 서비스 계층에 트랜잭션이 없음
• 회원, 로그 리포지토리가 각각 트랜잭션을 가지고 있음
• 회원 리포지토리는 정상 동작하지만 로그 리포지토리에서 예외가 발생

outerTxOff_fail

• 사용자 이름에 로그예외라는 단어가 포함되어 있으면 LogRepository에서 런타임 예외 발생
• 트랜잭션 AOP는 해당 런타임 예외를 확인하고 롤백 처리함

 /**
 * MemberService @Transactional:OFF
 * MemberRepository @Transactional:ON
 * LogRepository @Transactional:ON Exception
 */
@Test
void outerTxOff_fail() {
           //given
           String username = "로그예외_outerTxOff_fail";

           //when
           assertThatThrownBy(() -> memberService.joinV1(username))
                     .isInstanceOf(RuntimeException.class);

           //then: 완전히 롤백되지 않고, member 데이터가 남아서 저장된다.
           assertTrue(memberRepository.find(username).isPresent());
           assertTrue(logRepository.find(username).isEmpty());
}

로그예외 로직

if (logMessage.getMessage().contains("로그예외")) {
       log.info("log 저장시 예외 발생");
       throw new RuntimeException("예외 발생");
}

• 트랜잭션이 정상 커밋되고, 회원 데이터도 DB에 정상 반영 됨
• MemberService에서 LogRepository를 호출하는데, 로그예외라는 이름을 전달, 이 과정에서 새로운 트랜잭션 C가 만들어짐

LogRepository 응답 로직

• LogRepository는 트랜잭션C와 관련된 con2를 사용
• 로그예외라는 이름을 전달 LogRepository에 런타임 예외가 발생
• LogRepository는 해당 예외를 밖으로 던짐, 이 경우 트랜잭션 AOP가 예외를 받음
• 런타임 예외가 발생해서 트랜잭션 AOP는 트랜잭션 매니저에 롤백을 호출
• 트랜잭션 매니저는 신규 트랜잭션이므로 물리 롤백을 호출

참고

• 트랜잭션 AOP는 결국 내부에서 트랜잭션 매니저를 사용함
• 이 경우 회원은 저장되지만, 회원 이력 로그는 로백 됨, 따라서 데이터 적합성에 문제가 발생할 수 있음, 둘을 하나의 트랜잭션으로 묶어서 처리해 보자

트랜잭션 전파 활용3 - 단일 트랜잭션

트랜잭션 하나만 사용하기

• 회원 리포지토리와 로그 리포지토리를 하나의 트랜잭션으로 묶는 가장 간단한 방법은 이 둘을 호출하는 회원 서비스에만 트랜잭션을 사용하는 것

singleTx

/**
 * MemberService @Transactional:ON
 * MemberRepository @Transactional:OFF
 * LogRepository @Transactional:OFF
 */
@Test
void singleTx() {
             //given
             String username = "singleTx";

             //when
             memberService.joinV1(username);

             //then: 모든 데이터가 정상 저장된다.
             assertTrue(memberRepository.find(username).isPresent());
             assertTrue(logRepository.find(username).isPresent());
}

MemberService - joinV1()

@Transactional 
public void joinV1(String username)

MemberRepository - save()

//@Transactional //제거
public void save(Member meber)

LogRepository - save()

//@Transactional //제거
public void save(Log logMessage)

• MemberRepository, LogRepository의 @Transactioanl 코드 제거
• 그리고 MemberService에만 @transactional 코드 추가

• 이렇게 하면 MemberService를 시작할 때 부터 종료할 때 까지 모든 로직을 하나의 트랜잭션으로 묶을 수 있음
• 물론 MemberService가 MemberRepository, LogRepository를 호출하므로 이 로직들은 같은 트랜잭션을 사용
• MemberService만 트랜잭션을 처리하기 떄문에 앞서 배운 논리 트랜잭션, 물리 트랜잭션, 외부 트랜잭션, 내부 트랜잭션, rollbackOnly, 신규 트랜잭션, 트랜잭션 전파와 같은 복잡한 것을 고민할 필요 없고, 단순하고 깔끔하게 트랜잭션을 묶을 수 있음

• @transactional이 MemberService에만 붙어있기 때문에 여기에만 트랜잭션 AOP 적용 됨
• MemberRepository, LogRepository는 트랜잭션 AOP가 적용되지 않음
• MemberService의 시작부터 끝까지, 관련 로직은 해당 트랜잭션이 생성한 커넥션을 사용
• MemberService가 호출하는 MemberRepositor, LogRepository도 같은 커넥션을 사용하면서 자연스럽게 트랜잭션 범위에 포함

참고

• 같은 쓰레드를 사용하면 트랜잭션 동기화 매니저는 같은 커넥션을 반환

각각 트랜잭션이 필요한 상황(아래 문제 발생 상황)

• 클라이언트 A는 MemberService 부터 MemberRepository , LogRepository 를 모두 하나의 트랜잭션
  으로 묶고 싶음
• 클라이언트 B는 MemberRepository 만 호출하고 여기에만 트랜잭션을 사용하고 싶음
• 클라이언트 C는 LogRepository 만 호출하고 여기에만 트랜잭션을 사용하고 싶음
• 클라이언트 A만 생각하면 MemberService 에 트랜잭션 코드를 남기고, MemberRepository ,
  LogRepository 의 트랜잭션 코드를 제거하면 앞서 배운 것 처럼 깔끔하게 하나의 트랜잭션을 적용 가능
• 하지만 이렇게 되면 클라이언트 B, C가 호출하는 MemberRepository , LogRepository 에는 트랜잭션을
  적용할 수 없음

• 클라이언트 Z가 호출하는 OrderService에서도 트랜잭션을 시작할 수 있어야 하고, 클라이언트 A가 호출하는 MemberService에서도 트랜잭션을 시작할 수 있어야 함

###트랜잭션 전파 활용4 - 전파 커밋

• 스프링은 @transactional이 적용되어 있으면 기본적으로 REQUIRED라는 전파 옵션 사용
• 이 옵션은 기존 트랜잭션이 없으면 트랜잭션 생성하고, 기존 트랜잭션이 있으면 기존 트랜잭션 참여
• 참여한다는 것은 해당 트랜잭션을 그대로 따름, 동시에 같은 동기화 커넥션을 사용한다는 뜻

• 둘 이상의 트랜잭션이 하나의 물리 트랜잭션에 묶이게 되면 둘을 구분하기 위해 논리 트랜잭션과 물리 트랜잭션으로 구분

• 이 경우 외부에 있는 신규 트랜잭션만 실제 물리 트랜잭션을 시작하고 커밋함
• 내부에 있는 트랜잭션은 물리 트랜잭션 시작하거나 커밋하지 않음

모든 논리 트랜잭션 커밋

• 모든 논리 트랜잭션이 정상 커밋해야 물리 트랜잭션도 커밋 됨, 하나라도 롤백되면 물리 트랜잭션은 롤백 됨

outerTxOn_success

/**
 * MemberService @Transactional:ON
 * MemberRepository @Transactional:ON
 * LogRepository @Transactional:ON
 */
@Test
void outerTxOn_success() {
                   //given
                   String username = "outerTxOn_success";

                   //when
                   memberService.joinV1(username);

                   //then: 모든 데이터가 정상 저장된다.
                   assertTrue(memberRepository.find(username).isPresent());
                   assertTrue(logRepository.find(username).isPresent());
}

• MemberService @transactional:ON
• MemberRepository @transactional:ON
• LogRepository @transactional:ON

• 클라이언트A가 MemberService를 호출하면서 트랜잭션 AOP 호출 : 여기 신규 트랜잭션 생성되고, 물리 트랜잭션도 시작
• MemberRepository를 호출하면서 트랜잭션 AOP 호출 : 이미 트랜잭션이 있고 기존 트랜잭션에 참여
• MemberRepository의 로직 호출이 끝나고 정상 응답하면 트랜잭션 AOP가 호출 : 트랜잭션 AOP는 정상 응답이므로 트랜잭션 매니저에 커밋 요청, 이 경우 신규 트랜잭션이 아니므로 실제 커밋을 호출하지 않음
• LogRepository를 호출하면서 트랜잭션 AOP가 호출 : 이미 트랜잭션이 있으므로 기존 트랜잭션에 참여
• LogRepository의 로직 호출이 끝나고 정상 응답하면 트랜잭션 AOP가 호출 : 트랜잭션 AOP는 정상 응답이므로 트랜잭션 매니저에 커밋 요청, 이 경우 신규 트랜잭션이 아니므로 실제 커밋(물리 커밋)을 호출하지 않음
• MemberService의 로직 호출이 끝나고 정상 응답하면 트랜잭션 AOP가 호출 됨 : 트랜잭션 AOP는 정상 응답이므로 트랜잭션 매니저에 커밋을 요청, 이 경우 신규 트랜잭션이므로 물리 커밋을 호출

###트랜잭션 전파 활용5 - 전파 롤백

outerTxOn_fail

/**
 * MemberService @Transactional:ON
 * MemberRepository @Transactional:ON
 * LogRepository @Transactional:ON Exception
 */
@Test
void outerTxOn_fail() {
               //given
               String username = "로그예외_outerTxOn_fail";

               //when
               assertThatThrownBy(() -> memberService.joinV1(username))
               .isInstanceOf(RuntimeException.class);

               //then: 모든 데이터가 롤백된다.
               assertTrue(memberRepository.find(username).isEmpty());
               assertTrue(logRepository.find(username).isEmpty());
}

• MemberService @transactional:ON
• MemberRepository @transactional:ON
• LogRepository @transactional:ON

여기서는 로그예외로 넘겼기 때문에 LogRepository에서 런타임 예외 발생

• 클라이언트A가 MemberService를 호출하면서 트랜잭션 AOP 호출 : 여기서 신규 트랜잭션이 생성되고, 물리 트랜잭션도 시작
• MemberRepository를 호출하면서 트랜잭션 AOP 호출 : 이미 트랜잭션이 있으므로 기존 트랜잭션에 참여
• MemberRepository의 호출이 끝나고 정상 응답하면 트랜잭션 AOP가 호출 : 트랜잭션 AOP는 정상 응답이므로 트랜잭션 매니저에 커밋 요청, 이 경우 신규 트랜잭션이 아니므로 실제 커밋 호출하지 않음
• LogRepository를 호출하면서 트랜잭션 AOP 호출 : 이미 트랜잭션이 있어, 기존 트랜잭션에 참여
• LogRepository 로직에서 런타임 예외가 발생, 예외를 던지면 트랜잭션 AOP가 해당 예외를 받음 : 트랜잭션 AOP는 런타임 예외가 발생했으므로 트랜잭션 매니저에 롤백을 요청, 이 경우 신규 트랜잭션이 아니므로 물리 롤백을 호출하지 않음, 대신에 rollbackOnly를 설정
• LogRepository가 예외를 던졌기 떄문에 트랜잭션 AOP도 해당 예외를 그대로 밖으로 던짐
• MemberService에서도 런타임 예외를 받게 됨, 여기 로직에서는 해당 런타임 예외를 처리하지 않고 밖으로 던짐 : 트랜잭션 AOP는 런타임 예외가 발생했으므로 트랜잭션 매니저에 롤백을 요청, 이 경우 신규 트랜잭션이므로 물리 롤백을 호출, 참고로 이 경우 어차피 롤백이 되었기 떄문에, rollbackOnly 설정은 참고하지 않음, MemberService가 예외를 던졌기 때문에 트랜잭션 AOP도 해당 예외를 그대로 밖으로 던짐
• 클라이언트 A는 LogRepository 부터 넘어온 런타임 예외를 받음

정리

• 회원과 회원 이력 로그를 처리하는 부분을 하나의 트랜잭션으로 묶은 덕분에 문제가 발생했을 때 회원관 회원 이력 로그가 모두 함께 롤백 됨, 따라서 데이터 적합성에 문제가 발생하지 않음
  트랜잭션 전파 활용6 - 복구 REQUIRED

회원 가입을 시도한 로그를 남기는데 실패하더라도 회원 가입은 유지되어야 함

• 단순하게 생각하면 LogRepository에서 예외가 발생하면 그것을 MemberService에서 예외를 잡아서 처리하면 될 것 같음
• 이렇게 하면 MemberService에서 정상 흐름으로 바꿀 수 있기 때문에 MemberService의 트랜잭션 AOP에서 커밋을 수행할 수 있음, 근데 좀 이상함 -> 실패함

실패하는 이유

recoverException_fail

/**

• MemberService @transactional:ON

• MemberRepository @transactional:ON

• LogRepository @transactional:ON Exception
  */
  @test
  void recoverException_fail() {
  //given
  String username = "로그예외_recoverException_fail";

    //when
    assertThatThrownBy(() -> memberService.joinV2(username))
    .isInstanceOf(UnexpectedRollbackException.class);
  
    //then: 모든 데이터가 롤백된다.
    assertTrue(memberRepository.find(username).isEmpty());
    assertTrue(logRepository.find(username).isEmpty());
  

}

모든 트랜잭션을 켜자

• MemberService @transactional:ON
• MemberRepository @transactional:ON
• LogRepository @transactional:ON

여기서 memberService.joinV2()를 호출하는 부분을 주의해야 함, JoinV2()에는 예외를 잡아서 정상 흐름으로 변환하는 로직이 추가 됨

try {
       logRepository.save(logMessage);
} catch (RuntimeException e) {
       log.info("log 저장에 실패했습니다. logMessage={}", logMessage);
       log.info("정상 흐름 변환");
}

• 내부 트랜잭션에서 rollbackOnly를 설정하기 떄문에 결과적으로 정상 흐름 처리를 해서 외부 트랜잭션에서 커밋을 호출해도 물리 트랜잭션은 롤백 됨
• 그리고 UnexpectedRollbackException 던져짐

• LogRepository에서 예외가 발생, 예외를 던지면 LogRepository의 트랜잭션 AOP가 해당 예외를 받음
• 신규 트랜잭션이 아니라 물리 트랜잭션을 롤백하지 않고, 트랜잭션 동기화 매니저에 rollbackOnly를 표시
• 이후 트랜잭션 AOP는 전달 받은 예외를 밖으로 던짐
• 예외가 MemberService에 던져지고, MemberService는 해당 예외를 복구, 그리고 정상적으로 리턴함
• 정상 흐름이 되었으므르 MemberService의 트랜잭션 AOP는 커밋을 호출
• 커밋을 호출할 떄 신규 트랜잭션이므로 실제 물리 트랜잭션을 커밋해야 함, 이때 rollbackOnly 체크
• rollbackOnly가 체크 되어 있으므로 물리 트랜잭션을 롤백
• 트랜잭션 매니저는 UnexpectedRollbackException 예외를 던짐
• 트랜잭션 AOP도 전달 받은 UnexpectedRollbackException을 클라이언트에 던짐

정리

• 논리 트랜잭션 중 하나라도 롤백되면 전체 트랜잭션은 롤백 됨
• 내부 트랜잭션이 롤백 되었는데, 외부 트랜잭션이 커밋되면 UnexpectedRollbackException 예외가 발생
• rollbackOnly 상황에서 커밋이 발생하면 UnexpectedRollbackException 예외가 발생

트랜잭션 전파 활용7 - 복구 REQUIRES_NEW

그렇다면 어떻게 해야 다음 요구사항을 만족할 수 있을까?
회원 가입을 시도한 로그를 남기는데 실패하더라도 회원 가입은 유지 필요

recoverException_success

/**

• MemberService @transactional:ON

• MemberRepository @transactional:ON

• LogRepository @transactional(REQUIRES_NEW) Exception
  */
  @test
  void recoverException_success() {
  //given
  String username = "로그예외_recoverException_success";

    //when
    memberService.joinV2(username);
   
     //then: member 저장, log 롤백
    assertTrue(memberRepository.find(username).isPresent());
    assertTrue(logRepository.find(username).isEmpty());
  

}

• MemberService @transactional:ON
• MemberRepository @transactional:ON
• LogRepository @transactional(REQUIRES_NEW)

LogRepository - save()

@Transactional(propagation = Propagation.REQUIRES_NEW) //새롭게 적용
public void save(Log logMessage)

• MemberRepository는 REQUIRED 옵션을 사용, 따라서 기존 트랜잭션에 참여
• LogRepository의 트랜잭션 옵션에 REQUIRES_NEW를 사용
• REQUIRES_NEW는 항상 새로운 트랜잭션을 만듬, 따라서 해당 트랜잭션 안에서는 DB 커넥션도 별도로 사용하게 됨

REQUIRES_NEW - 복구

• REQUIRES_NEW를 사용하게 되면 물리 트랜잭션 자체가 완전히 분리 됨
• 그리고 REQUIRES_NEW는 신규 트랜잭션이므로 rollbackOnly 표시가 되지 않음, 그냥 해당 트랜잭션이 물리 롤백 됨

• LogRepository에서 예외가 발생, 예외를 던지면 LogRepository의 트랜잭션 AOP가 해당 예외를 받음
• REQUIRES_NEW를 사용한 신규 트랜잭션이므로 물리 트랜잭션을 롤백함, 물리 트랜잭션을 롤백했으므로 rollbackOnly를 표시하지 않음, 여기서 REQUIRES_NEW를 사용한 물리 트랜잭션은 롤백되고 완전히 끝이 남
• 이후 트랜잭션 AOP는 전달 받은 예외를 밖으로 던짐
• 예외가 MemberService에 던져지고, MemberService는 해당 예외를 복구함, 그리고 정상적으로 리턴
• 정상 흐름이 되었을 때 MemberService의 트랜잭션 AOP는 커밋을 호출
• 커밋을 호출할 때 신규 트랜잭션이므로 실제 물리 트랜잭션을 커밋해야 함, 이때 rollbackOnly를 체크
• rollbackOnly가 없으므로 물리 트랜잭션을 커밋
• 이후 정상 흐름이 반환

결과적으로 회원 데이터는 저장되고, 로그 데이터만 롤백 되는 것을 확인

정리

• 논리 트랜잭션은 하나라도 롤백되면 관련된 물리 트랜잭션은 롤백되어 버림
• 이 문제를 해결하려면 REQUIRES_NEW를 사용해서 트랜잭션을 분리해야 함
• 참고로 예제를 단순화 하기 위해 MemberService가 MemberRepository, LogRepository만 호출하지만 실제로는 더 많은 리포지토리들을 호출하고 그 중에 LogRepository만 트랜잭션을 분리한다고 생각하면 됨

주의

• REQUIRES_NEW를 사용하면 하나의 HTTP 요청에 동시에 2개의 DB 커넥션을 사용하게 됨, 따라서 성능이 중요한 곳에서는 이런 부분을 주의해서 사용해야 함

REQUIRES_NEW를 사용하지 않고 구조를 변경하는 것

• 이렇게 하면 HTTP 요청에 동시에 2개의 커넥션을 사용하지 않고, 순차적으로 사용하고 반환