[스프링 DB 2편] #9. 스프링 트랜잭션 이해(2)

[YONGHYNG]

인터페이스에 @transactional 적용

• 인터페이스에도 @transactional을 적용 가능, 아래와 같은 순서대로 적용

• 구체적인 것이 더 높은 우선순위를 가짐

• 1, 클래스의 메서드(우선순위 가장 높음)

• 2. 클래스의 타입
• 3. 인터페이스 메서드
• 4. 인터페이스의 타입(우선순위가 가장 낮음)

• 클래스의 메서드를 찾고, 만약 없으면 클래스의 타입을 찾고 만약 없으면 인터페이스의 메서드를 찾고 그래도 없으면 인터페이스의 타입을 찾음

• 인터페이스에 @transactional 사용하는 것은 스프링 공식 메뉴얼에서 권장하지 않음

• AOP를 사용하는 방식에 따라서 인터페이스에 에노테이션을 두면 AOP가 적용이 되지 않는 경우도 있기 때문

• 구체 클래스에 @transactional을 사용 필요

트랜잭션 AOP 주의 사항 - 프록시 내부 호출1

• @transactional을 사용하면 스프링의 트랜잭션 AOP가 적용
• 트랜잭션 AOP는 기본적으로 프록시 방식의 AOP를 사용
• @transactional을 적용하면 프록시 객체가 요청을 먼저 받아서 트랜잭션을 처리, 실제 객체를 호출해 줌
• 따라서 트랜잭션을 적용하려면 항상 프록시를 통해서, 대상 객체(Target) 호출 필요
• 이렇게 해야 프록시에서 먼저 트랜잭션을 적용, 이후 대상 객체 호출하게 됨
• 만약 프록시를 거치지 않고 대상 객체를 직접 호출하게 되면 AOP가 적용되지 않고, 트랜잭션도 적용되지 않음

• AOP를 적용하면 스프링은 대상 객체 대신에 프록시를 스프링 빈으로 등록
• 따라서 스프링은 의존관계 주입시에 항상 실제 객체 대신에 프록시 객체 주입
• 프록시 객체가 주입되기 떄문에 대상 객체를 직접 호출하는 문제는 일반적으로 발생하지 않음
• 하지만 대상 객체의 내부에서 메서드 호출이 발생하면 프록시를 거치지 않고 대상 객체를 직접 호출하는 문제가 발생, 이렇게 되면 @transactional이 있어도 트랜잭션이 적용되지 않음

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 InternalCallV1Config {
        @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을 통해 트랜잭션을 적용

@Transactional 이 하나라도 있으면 트랜잭션 프록시 객체가 만들어짐, callService 빈을 주입 받으면 트랜잭션 프록시 객체가 대신 주입 됨

@Test
void printProxy() {
       log.info("callService class={}", callService.getClass());
}

• 여기서는 테스트에서 callService를 주입 받음, 해당 클래스를 출력하면 뒤에 CGLIB... 붙음 원본 객체 대신에 트랜잭션을 처리하는 프록시 객체를 주입 받음

internalCall() 실행

• internalCall()은 트랜잭션이 있는 코드인 internal()을 호출 함

internal()

@Transactional
public void internal() {
         log.info("call internal");
         printTxInfo();
}

• 1. 클라이언트인 테스트 코드는 callService.internal()을 호출, 여기서 callService는 트랜잭션 프록시임
• 2. callService의 트랜잭션 프록시가 호출
• 3. internal() 메서드에 @transactional이 있으면 트랜잭션 프록시는 트랜잭션 적용
• 4. 트랜잭션 적용 후 실제 callService 객체 인스턴스의 internal()을 호출
• 실제 callService가 처리를 완료하면 응답이 트랜잭션 프록시로 들어오고, 트랜잭션 프록시는 트랜잭션을 완료함

실행 로그 - internalCall()

• TransactionInterceptor가 남긴 로그를 통해 트랜잭션 프록시가 트랜잭션을 적용한 것을 확인할 수 있음
• CallService가 남긴 tx active=true 로그를 통해 트랜잭션이 적용되어 있음을 확인

externalCall() 실행

• externalCall()은 트랜잭션이 없는 코드인 external()을 호출

external()

public void external() {
       log.info("call external");
       printTxInfo();
       internal();
}

@Transactional
public void internal() {
       log.info("call internal");
       printTxInfo();
}

• external()은 @transactional 애노테이션이 없음, 따라서 트랜잭션 없이 시작
• 그런데 내부에서 @transactional이 있는 internal()을 호출하는 것을 확인 가능
• 이 경우 external()은 트랜잭션이 없지만, internal()에서는 트랜잭션이 적용되는 것 처럼 보임

실행 로그 - externalCall()

• 실행 로그를 보면 트랜잭션 관련 코드가 보이지 ㅇ낳음
• 프록시가 아닌 실제 callService에서 남긴 로그만 확인 가능, 추가로 internal() 내부에서 호출한 tx activce=false 로그를 통해 확실히 트랜잭션이 수행되지 않은 것을 확인 가능
• 우리의 기대와 다르게 internal()에서 트랜잭션이 전혀 적용되지 않음, 왜 이런 문제가 발생할까??

프록시의 내부 호출

• 1. 클라이언트인 테스트 코드는 callService.external() 호출, 여기서 callService는 트랜잭션 프록시
• 2. callService의 트랜잭션 프록시가 호출
• 3. external() 메서드에는 @transactional이 없음, 따라서 트랜잭션 프록시는 트랜잭션을 저용하지 않음
• 4. 트랜잭션 적용하지 않고, 실제 callService 객체 인스턴스의 external()을 호출
• 5. external()은 내부에서 internal() 메서드 호출 여기서 문제 발생

문제 원인

• 자바 언어에서 메서드 앞에 별도의 참조가 없으면 this라는 뜻으로 자기 자신의 인스턴스를 가리킴, 결과적으로 자기 자신의 내부 메서드를 호출하는 this.internal()이 되는데, 여기서 this는 자기 자신을 가리키므로, 실제 대상 객체(target)의 인스턴스 뜻함
• 결과적으로 이러한 내부 호출은 프록시를 거치지 않음, 따라서 트랜잭션을 적용할 수 없음, 즉 target에 있는 internal()을 직접 호출 함

프록시 방식의 AOP 한계

• @transactional를 사용하는 트랜잭션 AOP는 프록시를 사용, 프록시를 사용하면 메서드 내부 호출에 프록시를 적용할 수 없음
• 이 문제를 해결할 가장 간단한 방법 internal() 메서드를 별도의 클래스로 분리

트랜잭션 AOP 주의 사항 - 프록시 내부 호출2

• 메서드 내부 호출 떄문에 트랜잭션 프록시가 적용되지 않는 문제를 해결하기 위해 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;

@SpringBootTest
public class InternalCallV2Test {

    @Autowired
    CallService callService;

    @Test
    void externalCallV2() {
        callService.external();
    }

    @TestConfiguration
    static class InternalCallV2Config {
        @Bean
        CallService callService() {
            return new CallService(innerService());
        }

        @Bean
        InternalService innerService() {
            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에는 트랜잭션 관련 코드가 있으므로 트랜잭션 프록시가 적용

실제 호출되는 흐름 분석

• 1. 클라이언트인 테스트 코드는 callService.external()을 호출
• 2. callService는 실제 callService 객체 인스턴스
• 3. callService는 주입 받은 internalService.internal()을 호출
• 4. internalService는 트랜잭션 프록시, internal() 메서드에 @transactional이 붙음 트랜잭션 프록시는 트랜잭션을 적용
• 5. 트랜잭션 적용 후 실제 internalService 객체 인스턴스의 internal()을 호출

실행 로그 - externalCallV2()

• TransactionInterceptor를 통해 트랜잭션이 적용 된 것이 확인 가능
• InternalService의 tx active=true 로그를 통해 internal() 호출해서 트랜잭션이 적용된 것을 확인 가능, 이렇게 별도의 클래스로 분리하는 방법 주로 사용

public 메서드만 트랜잭션 적용

• 스프링의 트랜잭션 AOP 기능은 public 메서드에만 트랜잭션을 적용하도록 기본 설정 되어 있음
• protected , private , package-visible 에는 트랜잭션이 적용되지 않음

스프링이 public에만 트랜잭션을 적용하는 이유

@Transactional
public class Hello {
     public method1();
     method2():
     protected method3();
     private method4();
}

• 이렇게 클래스 레벨이 트랜잭션을 적용하면 모든 메서드에 트랜잭션이 걸릴 수 있음
• 그러면 트랜잭션을 의도하지 않는 곳 까지 트랜잭션이 과도하게 적용
• 트랜잭션은 주로 비즈니스 로직의 시작점에 걸기 때문에 대부분 외부에 열어준 곳을 시작점으로 사용, 이런 이유로 public 메서드에만 트랜잭션을 적용하도록 설정
• 앞서 실행한 코드를 package-visible로 변경해보면 적용되지 않는 것을 확인
• public이 아닌 곳에 @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.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;

import javax.annotation.PostConstruct;

@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을 함께 사용하면 트랜잭션이 적용되지 않음

@PostConstruct
@Transactional
public void initV1() {
         log.info("Hello init @PostConstruct");
}

• 이유는 초기화 코드가 먼저 호출되고, 그 다음에 트랜잭션 AOP가 적용되기 떄문, 따라서 초기화 시점에는 해당 메서드에서 트랜잭션을 획득할 수 없음

initV1() 관련 로그

Hello init @PostConstruct tx active=false

• 가장 확실한 대안은 ApplicationReadyEvent 이벤트를 사용하는 것

@EventListener(value = ApplicationReadyEvent.class)
@Transactional
public void init2() {
     log.info("Hello init ApplicationReadyEvent");
}

• 이 이벤트는 트랜잭션 AOP를 포함한 스프링이 컨테이너가 완전히 생성되고, 다음에 이벤트가 붙은 메서드를 호출, 따라서 init2()는 트랜잭션이 적용된 것이 확인

init2() ApplicationReadyEvent 이벤트가 호출하는 코드

트랜잭션 옵션 소개 - 추가 기능

@transactional - 코드

public @interface Transactional {
    String value() default "";
    String transactionManager() default "";
    Class<? extends Throwable>[] rollbackFor() default {};
    Class<? extends Throwable>[] noRollbackFor() default {};
    Propagation propagation() default Propagation.REQUIRED;
    Isolation isolation() default Isolation.DEFAULT;
    int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;
    boolean readOnly() default false;
    String[] label() default {};
}

• value, transactionManager : @transactional에서도 트랜잭션 프록시가 사용할 트랜잭션 매니저를 지정해야 함
• 사용할 트랜잭션 매니저를 지정할 때는 value, transactionManager 둘 중 하나에 트랜잭션 매니저의 스프링 빈의 이름을 적어주면 됨
• 이 값을 생략하면 기본으로 등록된 트랜잭션 매니저를 사용하기 때문에 생략, 그런데 사용하는 트랜잭션 매니저가 둘 이상이라면 다음과 같이 트랜잭션 매니저의 이름을 지정해서 구분해야 함

public class TxService {

               @Transactional("memberTxManager")
               public void member() {...}

               @Transactional("orderTxManager")
               public void order() {...}
}

• 참고로 애노테이션에서 속성이 하나인 경우 위 예처럼 value는 생량하고 값을 넣을 수 있음

rollbackFor

• 예외 발생시 스프링 트랜잭션의 기본 정책은 다음과 같음
• 1. 언체크 에외인 RuntimeException, Error 외 그 하위 예외가 발생하면 롤백
• 2. 체크 예외인 Exception과 그 하위 예외들은 커밋함
• 3. 아래 옵션을 지정하면 기본 정책에 추가로 어떤 예외가 발생할 때 롤백할 지 지정할 수 있음
• 3-1. @Transactional(rollbackFor = Exception.class) 이렇게 지정하면 체크 예외인 Exception이 발생해도 롤백함(하위 예외들도 대상에 포함)
• 3-2. rollbackForClassName 도 있는데, rollbackFor 는 예외 클래스를 직접 지정, rollbackForClassName 는 예외 이름을 문자로 넣으면 됨

noRollbackFor

• 위에 설명한 rollbackFor와 반대, 기본 정책에 추가로 어떤 예외가 발생했을 때 롤백하면 안 되는지 지정할 수 있음
• 예외 이름을 문자로 넣을 수 있는 noRollbackForClassName 있음

isolation

• 트랜잭션 격리 수준을 지정할 수 있음, 기본 값은 디비에 설정한 트랜잭션 격리 수준을 사용하는 DEFAULT 임

• 대부분 디비 설정할 기준을 따름

• 애플리케이션 개발자가 트랜잭션 격리 수준을 직접 지정하는 경우는 드뭄

• DEFAULT : 디비에서 설정한 격리 수준을 따름

• READ_UNCOMMITTED : 커밋되지 않은 읽기

• READ_COMMITED : 커밋된 읽기

• REPEATABLE_READ : 반복 가능한 읽기

• SERIALIZABLE : 직렬화 가능

timeout

• 트랜잭션 수행 시간에 대한 타임아웃을 초 단위로 지정, 기본 값은 트랜잭션 시스템의 타임아웃을 사용
• 운영 환경에 따라 동작하는 경우도 있고, 그렇지 않은 경우도 있기 때문에 꼭 확인하고 사용해야 함
• timeoutString도 있는데, 숫자 대신 문자 값으로 지정할 수 있음

label

• 트랜잭션 애노테이션에 있는 값을 직접 읽어서 어떤 동작을 하고 싶을 때 사용할 수 있음, 일반적으로 사용하지 않음

readOnly

• 트랜잭션은 기본적으로 읽기 쓰기 모두 가능한 트랜잭션이 생성
• readOnly = true 옵션을 사용하면 읽기 전용 트랜잭션 생성, . 이 경우 등록, 수정, 삭제가 안되고 읽기 기능만
  작동 (드라이버나 데이터베이스에 따라 정상 동작하지 않는 경우도 있음) 그리고 readOnlyy 옵션을 사용하면 읽기에서 다양한 성능 최적화가 발생할 수 있음

readOnly 옵션은 크게 3곳에서 적용

1. 프레임워크

• JdbcTemplate은 읽기 전용 트랜잭션 안에서 변경 기능을 실행하면 예외를 던짐
• JPA(하이버네이트)는 읽기 전용 트랜잭션의 경우 커밋 시점에 플러시를 호출하지 않음
• 읽기 전용이니 변경에 사용되는 플러시 호출할 필요 없음
• 추가로 변경이 필요 없으니 변경 감지를 위한 스냅샷 객체도 생성하지 않음

2. JDBC 드라이버

• 읽기 전용 트랜잭션에서 변경 쿼리가 발생하면 예외를 던짐
• 읽기, 쓰기(마스터, 슬레이브) 이비를 구분해서 요청함, 읽기 전용 트랜잭션의 경우 읽기(슬레이브)디비의 커넥션을 획득해서 사용

3. 데이터베이스

• 데이터베이스에 따라 읽기 전용 트랜잭션의 경우 읽기만 하면 됨, 내부에서 성능 최적화가 발생함