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

[YuDeokRin]

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

• @transactional을 사용하면 스프링 트랜잭션 AOP가 적용된다.
• 트랜잭션 AOP는 기본적으로 프록시 방식의 AOP를 사용한다.
• @transactional을 사용하면 프록시 객체가 요청을 먼저 받고 트랜잭션 처리 → 객체를 호출

• AOP를 적용하면 스프링은 프록시를 스프링 빈으로 등록한다. 스프링은 의존관계 주입시에 항상 실제 객체 대신에 프록시 객체를 주입한다.
• 프록시 객체가 주입되기 때문에 대상 객체를 직접 호출하는 문제는 일반적으로 발생하지 않는다.

주의
대상 객체의 내부에서 메서드 호출이 발생하면 프록시를 거치지 않고 대상 객체를 직접 호출하는 문제가 발생할 수 있음

• InternalCallV1Test

@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 InternalCallV1TestConfiguration {

        @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() : 트랜잭션이 없음 (@transactional)

• internal() : 트랜잭션이 있음 (@transactional)

• @transactional이 하나라도 있으면 트랜잭션 프록시 객체가 만들어진다. 그리고 callService 빈을 주입 받으면 트랜잭션 프록시 객체가 대신 주입된다.

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

• 위에서 테스트에서 callService를 주입 받는데, 해당 클래스를 출력해보면 뒤에 CGLIB가 붙어있는 것을 알수 있음 → 원본 객체를 주입 받는게아니라 트랜잭션을 처리하는 프록시 객체를 주입 받은 것이라고 보면된다.

2025-01-13T23:32:57.528+09:00  INFO 38576 --- [springtx] [    Test worker] h.springtx.apply.InternalCallV1Test      : callService class: class hello.springtx.apply.InternalCallV1Test$CallService$$SpringCGLIB$$0

✅ interalCall() 실행

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

• internal()

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

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

• 메서드 내부 호출 때문에 트랜잭션 프록시가 적용되지 않는 문제를 해결하기 위해 별도의 internal() 메서드를 클래스로 분리하자.

• InternalCallV2Test

@Slf4j
@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()

  • internal()

    2025-01-14T23:28:49.173+09:00 TRACE 39506 --- [springtx] [    Test worker] o.s.t.i.TransactionInterceptor           : Getting transaction for [hello.springtx.apply.InternalCallV2Test$InternalService.internal]
    2025-01-14T23:28:49.174+09:00  INFO 39506 --- [springtx] [    Test worker] h.s.a.InternalCallV2Test$InternalService : call internal
    2025-01-14T23:28:49.174+09:00  INFO 39506 --- [springtx] [    Test worker] h.s.a.InternalCallV2Test$InternalService : tx active=true
    2025-01-14T23:28:49.174+09:00 TRACE 39506 --- [springtx] [    Test worker] o.s.t.i.TransactionInterceptor           : Completing transaction for [hello.springtx.apply.InternalCallV2Test$InternalService.internal]

  • external()

    2025-01-14T23:28:49.151+09:00  INFO 39506 --- [springtx] [    Test worker] h.s.a.InternalCallV2Test$CallService     : call external
    2025-01-14T23:28:49.152+09:00  INFO 39506 --- [springtx] [    Test worker] h.s.a.InternalCallV2Test$CallService     : tx active=false

✅ public 메서드만 트랜잭션 적용

• 스프링 트랜잭션 AOP 기능은 public 메서드에만 트랜잭션을 적용하도록 기본 설정이 되어있음
• protected, private, package-visible에는 트랜잭션이 적용되지 않는다.
• protected, Package-visible도 외부에서 호출이 가능하다. 따라서 이 부분은 앞서 설명한 프록시의 내부 호출과는 무관하고, 스프링이 막아둔 것이다.

7️⃣ 트랜잭션 AOP 주의 사항 - 초기화 시점

@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가 적용되기 때문이다. 따라서 초기화 시점에는 해당 메서드에서 트랜잭션을 획득할 수 없다.

8️⃣ 트랜잭션 옵션 소개

• 스프링

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 둘 중 하나에 트랜잭션 매니저의 스프링 빈의 이름을 적어주면 된다. 이 값을 생략하면 기본으로 등록된 트랜잭션 매니저를 사용하기 때문에 대부분 생략한다.
• 그런데 사용하는 트랜잭션 매니저가 둘 이상이라면 다음과 같이 트랜잭션 매니저의 이름을 지정해서 구분하면 된다.

✅ rollback

• 예외 발생시 스프링 트랜잭션의 기본 정책은 다음과 같다.
• 언체크 예외인 RuntimeException , Error 와 그 하위 예외가 발생하면 롤백한다. 체크 예외인 Exception 과 그 하위 예외들은 커밋한다.

⏺️ noRollbackFor

• 앞서 설명한 rollbackFor 와 반대이다. 기본 정책에 추가로 어떤 예외가 발생했을 때 롤백하면 안되는지 지정할 수있다.

• 예외 이름을 문자로 넣을 수 있는 noRollbackForClassName 도 있다.

• propagation

propagation
트랜잭션 전파에 대한 옵션이다. 자세한 내용은 뒤에서 설명한다.

• isolation
  • 트랜잭션 격리 수준을 지정할 수 있다. 기본 값은 데이터베이스에서 설정한 트랜잭션 격리 수준을 사용하는 DEFAULT이다.
  • 대부분 데이터베이스에서 설정한 기준을 따른다. 애플리케이션 개발자가 트랜잭션 격리 수준을 직접 지정하는 경우는 드물다.
  • DEFAULT : 데이터베이스에서 설정한 격리 수준을 따른다.
  • READ_UNCOMMITTED : 커밋되지 않은 읽기
  • READ_COMMITTED : 커밋된 읽기
  • REPEATABLE_READ : 반복 가능한 읽기
  • SERIALIZABLE : 직렬화 가능

timeout

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

timeoutString도 있는데, 숫자 대신 문자 값으로 지정할 수 있다.