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

[YuDeokRin]

스프링 트랜잭션 이해

1️⃣ 스프링 트랜잭션 소개

✅ 스프링 트랜잭션 추상화

• 각각의 데이터 접근 기술들은 트랜잭션의 처리하는 방식에 차이가 있음 .

  • JDBC 트랜잭션 코드
  • JPA 트랜잭션 코드

• JDBC 트랜잭션 코드 예시)

public void accountTransfer(String fromId, String toId, int money) throws SQLException {
   Connection con = dataSource.getConnection();
   try {
			   con.setAutoCommit(false); //트랜잭션 시작 //비즈니스 로직
				 bizLogic(con, fromId, toId, money); con.commit(); //성공시 커밋
	 } catch (Exception e) {
				 con.rollback(); //실패시 롤백
				 throw new IllegalStateException(e);
   } finally {
         release(con);
	 } 
}			 

• JPA 트랜잭션 코드 예시)

public static void main(String[] args) {

		 //엔티티 매니저 팩토리 생성
     EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook");
     EntityManager em = emf.createEntityManager(); //엔티티 매니저 생성 EntityTransaction tx = em.getTransaction(); //트랜잭션 기능 획득
     try {
		     tx.begin(); //트랜잭션 시작 logic(em); //비즈니스 로직 tx.commit();//트랜잭션 커밋
		 } catch (Exception e) { 
				 tx.rollback(); //트랜잭션 롤백
		 } finally {
				 em.close(); //엔티티 매니저 종료
     }
		 emf.close(); //엔티티 매니저 팩토리 종료 
}

• 두 개의 예시가 있다. 하지만 JDBC기술을 사용하다가 JPA로 변경하게 되면 트랜잭션을 사용하는 코드도 모두 변경해야한다는 비용이 발생한다.
• 위의 방법을 극복하기 위해 스프링은 트랜잭션 추상화를 제공한다.

✅ PlatformTransactionManager 인터페이스

package org.springframework.transaction;
 public interface PlatformTransactionManager extends TransactionManager {
	  
	  TransactionStatus getTransaction(@Nullable TransactionDefinition definition) throws TransactionException;
    void commit(TransactionStatus status) throws TransactionException;
    void rollback(TransactionStatus status) throws TransactionException;
}
****

• 트랜잭션은 트랜잭션 시작(획득), 커밋, 롤백으로 단순하게 추상화 할 수 있다.

• 스프링 부트는 어떤 데이터 접근 기술을 사용하는지를 자동으로 인식해서 적절한 트랜잭션 매니저를 선택해서 스프링 빈으로 등록해주기 때문에 트랜잭션 매니저를 선택하고 등록하는 과정도 생략할 수 있다.
  • 예시) JdbcTemplate, MyBatis → JdbcTransactionManager

✅ 스프링 트랜잭션 사용 방식

• 선언적 트랜잭션 관리 vs 프로그래밍 방식 트랜잭션 관리

• 선언적 트랜잭션 관리(Declarative Transaction Management)

  • @transactional 애노테이션 하나만 선언해서 트랜잭션을 적용하는 것을 선언적 트랜잭션 관리라 한다.

• 프로그래밍 방식의 트랜잭션 관리(programmatic transaction management)

  • 트랜잭션 매니저 또는 트랜잭션 템플릿 등을 활용해서 트랜잭션을 관리

✅ 선언적 트랜잭션 AOP

• @transactional 을 통한 선언적 트랜잭션 관리 방식을 사용하게 되면 기본적으로 프록시 방식의 AOP가 적용된다.

//트랜잭션 시작
TransactionStatus status = transactionManager.getTransaction(new
DefaultTransactionDefinition());
try {
//비즈니스 로직
     bizLogic(fromId, toId, money);
		 transactionManager.commit(status); //성공시 커밋 } 
catch (Exception e) {
	   transactionManager.rollback(status); //실패시 롤백
     throw new IllegalStateException(e);
 }

• 프록시 도입후
  • 트랜잭션을 처리하는 객체와 비즈니스 로직 처리하는 서비스 객체를 명확하게 분리된다.

• 프록시 적용 전

public class TransactionProxy {
     
     private MemberService target;
	public void logic() { 
		//트랜잭션 시작
    TransactionStatus status = transactionManager.getTransaction(..);
    try {
		    //실제 대상 호출
		    target.logic(); 
		    transactionManager.commit(status); //성공시 커밋
		} catch (Exception e) { 
				transactionManager.rollback(status); //실패시 롤백 throw new IllegalStateException(e);
    }
  }
}

• 트랜잭션 프록시 적용 후 서비스 코드 예시

public class Service {
			public void logic() {
					//트랜잭션 관련 코드 제거, 순수 비즈니스 로직만 남음 bizLogic(fromId, toId, money);
      }
}

• 프록시 도입 후 전체과정
  • 트랜잭션은 커넥션에 con.setAutocommit(false) 를 지정하면서 시작한다.
  • 같은 트랜잭션을 유지하려면 같은 데이터베이스 커넥션을 사용해야 한다.
  • 이것을 위해 스프링 내부에서는 트랜잭션 동기화 매니저가 사용된다.
    • JdbcTemplate 을 포함한 대부분의 데이터 접근 기술들은 트랜잭션을 유지하기 위해 내부에서 트랜잭션 동기화 매니저를 통해 리소스(커넥션)를 동기화 한다

2️⃣ 프로젝트 생성

• Project : Gradle Project

• Language : Java 17

• Spring boot version : 3.4.1

• Project Metadata

  • Group : hello
  • Artifact : springtx
  • Name : springtx
  • Package name : hello.springtx

• Packaging : Jar

• Dependencies

  • Lombok
  • H2 Database - version :2.2.3.232
  • Spring Date JPA

• build.gradle

plugins {
    id 'java'
    id 'org.springframework.boot' version '3.4.1'
    id 'io.spring.dependency-management' version '1.1.7'
}

group = 'hello'
version = '0.0.1-SNAPSHOT'

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    compileOnly 'org.projectlombok:lombok'
    runtimeOnly 'com.h2database:h2'
    annotationProcessor 'org.projectlombok:lombok'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'

    //테스트에서 lombok 사용
    testCompileOnly 'org.projectlombok:lombok'
    testAnnotationProcessor 'org.projectlombok:lombok'
}

tasks.named('test') {
    useJUnitPlatform()
}

3️⃣ 트랜잭션 적용 확인

• @transactional을 통해 선언적 트랜잭션 방식을 사용하며 단순히 애노테이션 하나로 트랜잭션을 적용할 수 있다.
• 애너테이션을 사용하면 트랜잭션 관련 코드가 눈에 보이지 않고, AOP를 기반으로 동작하기 때문에 실제 트랜잭션이 적용되는지 확인이 어렵다.

➡️ 스프링 트랜잭션이 적용되는지 확인하는 방법을 알아보자.

• TxApplyBasicTest

@Slf4j
@SpringBootTest
public class TxbasicTest {

    @Autowired
    BasicService basicService;

    @Test
    void proxyCheek() {
        log.info("aop class={}", basicService.getClass());
        assertThat(AopUtils.isAopProxy(basicService)).isTrue() ; // 스프링 AOP 프록시로 적용이 되었는가 확인할 수 있음
    }

    @Test
    void txTest() {
        basicService.tx();
        basicService.nonTx();
    }

    @TestConfiguration
    static class TxApplyBasicConfig {

        @Bean
        BasicService basicService() {
            return new BasicService();
        }
    }

    @Slf4j
    static class BasicService {

        @Transactional
        public void tx() {
            log.info("call tx");
            boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();
            log.info("tx active: {}", txActive);

        }

        public void nonTx() {
            log.info("call nonTx");
            boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();
            log.info("tx active: {}", txActive);
        }
    }
}

• 위 코드 설명

  • proxyCheck() - 실행

    • AopUtils.isAopProxy() : 선억적 트랜잭션 방식에서 스프링 트랜잭션은 AOP를 기반으로 동작한다. Transactional을 메서드나 클래스에 붙이면 해당 객체는 트랜잭션 AOP 적용의 대상이 되고, 결과적으로 실제 객체 대신에 트랜잭션을 처리해주는 프록시 객체가 스프링 빈에 등록된다.
    • 주입을 받을 때도 실제 객체 대신에 프록시 객체가 주입된다.
    • 클래스 이름을 출력해보면$BasicService$$SpringCGLIB$$0 라고 프록시 클래스의 이름이 출력되는 것을 확인할 수 있다.

  • proxyCheck() - 실행 결과

    aop class=class hello.springtx.apply.TxbasicTest$BasicService$$SpringCGLIB$$0

• @Transcational 은 특정 클래스나 메서드에 하나라도 있으면 트랜잭션 AOP는 프록시를 만들어서 스프링 컨테이너에 등록한다.

• 실제 basicService 객체 대신에 프록시인 BasicService$$SpringCGLIB$$0 를 스프링 빈에 등록한다.

• 프록시는 내부에서 실제 basicService를 참조하게 된다.

• 핵심은 실제 객체 대신에 프록시가 스프링 컨테이너에 등록되었다는 점

• 클라이언트인 txBasicTest는 스프링 컨테이너에 @Autowired BasicService basicService로 의존관계 주입을 요청한다. 스프링 컨테이너에는 실제 객체 대신에 프록시가 스프링 빈으로 등록되어 있기 때문 프록시를 주입한다.

• 프록시는 BasicService 를 상속해서 만들어지기 때문에 다형성을 활용할 수 있다. 따라서 BasicService 대신에 프록시인 BasicService$$CGLIB 를 주입할 수 있다.

• 클라이언트가 주입 받은 basicService$$CGLIB 는 트랜잭션을 적용하는 프록시이다.

➡️로그 추가

• application.properties

logging.level.org.springframework.transaction.interceptor=TRACE

1️⃣ basicService.tx() 호출

• basicService.tx() 호출 → 프록시의 tx() 호출 → tx()가 트랜잭션을 사용할 수 있는지 확인

• @transactional이 붙어있는 경우 → 트랜잭션 적용 대상

• 따라서 트랜잭션을 시작한 다음 실제 basicService.tx()를 호출이 끝나서 프록시로 제어가(리턴) 돌아오면 프록시는 트랜잭션 로직을 커밋하거나 롤백해서 트랜잭션을 종료한다.

• 실행결과

2025-01-10T22:19:47.984+09:00 TRACE 34323 --- [springtx] [    Test worker] o.s.t.i.TransactionInterceptor           : Getting transaction for [hello.springtx.apply.TxbasicTest$BasicService.tx]
2025-01-10T22:19:47.985+09:00  INFO 34323 --- [springtx] [    Test worker] h.s.apply.TxbasicTest$BasicService       : call tx
2025-01-10T22:19:47.985+09:00  INFO 34323 --- [springtx] [    Test worker] h.s.apply.TxbasicTest$BasicService       : tx active: true
2025-01-10T22:19:47.985+09:00 TRACE 34323 --- [springtx] [    Test worker] o.s.t.i.TransactionInterceptor           : Completing transaction for [hello.springtx.apply.TxbasicTest$BasicService.tx]

2️⃣ basicService.nonTx() 호출

• basicService.nonTx() 호출 → 프록시의 nonTx() 호출 → nonTx()가 트랜잭션을 사용할 수 있는지 확인
• @transactional이 붙어있는 않은 경우 → 트랜잭션 적용 대상 X
• 트랜잭션 시작X → basicService.nonTx() 를 호출하고 종료한다.

2025-01-10T22:19:47.986+09:00  INFO 34323 --- [springtx] [    Test worker] h.s.apply.TxbasicTest$BasicService       : call nonTx
2025-01-10T22:19:47.986+09:00  INFO 34323 --- [springtx] [    Test worker] h.s.apply.TxbasicTest$BasicService       : tx active: false

✅ TransactionSynchronizationManager.isActualTransactionActive()

• 현재 쓰레드에 트랜잭션이 적용되어 있는지 확인할 수 있는 기능이다. 결과가 true면 트랜잭션이 적용되어 있는 것이다. 트랜잭션의 적용 여부를 가장 확실하게 확인할 수 있다.

4️⃣ 트랜잭션 적용 위치

• @transactional의 적용 위치에 따른 우선순위를 확인해보자.

• 스프링에서 우선순위는 항상 더 구체적이고 자세한 것이 높은 우선순위를 가진다.

  • 예) 클래스 vs 메소드 → 메소드가 더 구체적

• TxLevelTest

@SpringBootTest
public class TxLevelTest {
    
    @Autowired LevelService service;
    
    @Test
    void orderTest() {
        service.write();
        service.read();
    }
    
    @TestConfiguration
    static class TxApplyLevelConfig {
        @Bean
        LevelService levelService() {
            return new LevelService();
        }
    }

    @Slf4j
    @Transactional(readOnly = true)
    static class LevelService {

        @Transactional(readlOnly = false)
        public void write() {
            log.info("call write");
            printTxInfo();
        }
        
        public void read() {
            log.info("call read");
            printTxInfo();
        }

        private void printTxInfo() {
            boolean txActive = TransactionSynchronizationManager.isActualTransactionActive();
            log.info("tx active={}", txActive);

            boolean readOnly = TransactionSynchronizationManager.isCurrentTransactionReadOnly();
            log.info("tx readOnly = {}", readOnly);
        }
    }
    
}

• 스프링 @transactional의 두 가지 규칙
  1. 우선순위 규칙
  2. 클래스에 적용하면 메서드는 자동 적용

➡️ 우선순위

• 트랜잭션을 사용할 때는 옵션이 있음 옵션을 주지않으면 어떤 것이 선택되는지 확인해보자.

• LevelService의 타입에 @transactional(readOnly = true)

• write() : 해당 메서드에 @transactional(readOnly = false)

  • 이렇게 되면 타입에 있는 @transactional(readOnly = true) 와 해당 메서드에 있는@transactional(readOnly = false) 둘 중 하나를 적용해야 한다.
  • 클래스 보다는 메서드가 더 구체적이므로 메서드에 있는 @transactional(readOnly = false) 옵 션을 사용한 트랜잭션이 적용된다.

• 클래스에 적용하면 메서드는 자동 적용

  • read() : 해당 메서드에 @transactional이 없다. 이 경우 더 상위인 클래스를 확인한다.
    • 클래스에 @transactional(readOnly = true) 이 적용되어 있다. 따라서 트랜잭션이 적용되고 readOnly = true 옵션을 사용하게 된다.

참고로 readOnly=false 는 기본 옵션이기 때문에 보통 생략한다. 여기서는 이해를 돕기 위해 기본 옵션을 적어주었 다.@transactional == @transactional(readOnly=false) 와 같다

✅ 인터페이스에 @transactional 적용

• 인터페이스에도 애너테이션을 붙일 수 있다.

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

인터페이스에 @Transactional 사용하는 것은 스프링 공식 메뉴얼에서 권장하지 않는 방법이다.

🔗 출처

• 김영한 - 스프링 DB 2편 - 데이터 접근 활용 기술