[Spring] Transactional의 이해

💡 트랜잭션

🤔 트랜잭션이란?

트랜잭션이란 데이터베이스 혹은 유사 시스템에서 하나의 상호작용 단위이다.
이는 데이터의 정합성을 보장하기 위해 고안된 방법이다.

 

이는 데이터베이스를 일관성 있게 유지하고, 동시 접근하는 여러 프로그램 간의 격리를 제공하기 위해 존재한다.

트랜잭션 내 SQL문들은 모두 성공하여 commit 되거나, 하나라도 실패하는 경우 전체가 rollback 된다.

 

🫨 ACID

트랜잭션이 어떤 속성을 지녀야 하는지 나타내는 핵심이다.
4가지 규칙을 모두 보장해 안전하게 수행되어야 한다.

 

원자성(Atomicity)

• All or Noting
• 모두 성공 or 모두 실패

하나의 트랜잭션은 논리적으로 나누어질 수 없는 단위이기 때문에 동일한 경과를 보장해야 한다.

즉, 일부만 성공하거나 실패하는 상태는 존재해서 안 된다.

 

일관성(Consistency)

• 트랜잭션 이전과 이후 데이터베이스는 항상 일관적인 상태여야 한다.
  • 트랜잭션은 DB를 Consistency -> Consistency로 변경한다.

만약 DB의 정의된 규칙을 위반한다면 트랜잭션은 롤백되어야 한다.

예를 들어, 계좌 잔고가 -가 될 수 없도록 설정해 두었다면 이를 일관성 있게 지켜야 한다.

 

독립성(Isolation)

• 여러 트랜잭션이 동시 실행되어도, 하나의 트랜잭션은 독립적으로 동작하는 것이어야 한다.
• 트랜잭션 밖에 있는 어떠한 연산도 트랜잭션의 중간 연산을 볼 수 없어야 한다.
• DBMS는 여러 종류의 isolation level을 제공한다.

 

지속성(Durability)

• 성공적으로 수행된 트랜잭션은 영구적으로 반영되어야 한다.
• 전원이 꺼진 뒤에도 저장되는 비휘발성 메모리에 저장되어야 한다.

 

JDBC Template

catch (SQLException e) {
    try {
        connection.rollback();
    } catch (SQLException ex) {
        ex.addSuppressed(e);
        throw ex;
    }
    throw e;
}

 

🔎 단계별 의미

1️⃣ dataSource.getConnection()
→ DB 커넥션 획득

 

2️⃣ setAutoCommit(false)
→ 자동 커밋 끄기 (트랜잭션 시작)

 

3️⃣ 비즈니스 로직 수행
→ 여러 SQL 실행

 

4️⃣ commit()
→ 정상 종료 시 DB 반영

 

5️⃣ rollback()
→ 예외 발생 시 되돌리기

 

6️⃣ close()
→ 커넥션 반환 (보통 풀로 반환됨)

 

즉, 트랜잭션 경계를 개발자가 직접 제어하는 방식이다.

 

트랜잭션 범위가 메서드 내부에 고정되거나, AOP 기반 트랜잭션이 불가능하여 자주 사용되지는 않는다.

 

‼️ Spring Transaction

정의

스프링이 제공하는 추상화된 트랜잭션 관리 기능으로 개발자가 비즈니스 로직에만 집중할 수 있도록
트랜잭션 시작/커밋/롤백을 자동으로 처리해 주는 기능이다.

 

PlatformTransactionManager

 

Spring 트랜잭션 추상화의 중심 인터페이스이다.

commit와 rollback 메서드를 가지고 있다.

JDBC, JPA 등 모두 이를 구현하여 Spring Transaction을 지원한다.

이를 통해 기술에 독립적이고, 트랜잭션 경계설정이 가능해졌다.

org.springframework.transaction.PlatformTransactionManager 경로에 존재하며

현재 활성화된 트랜잭션을 반환하거나, 지정된 전파(propagation) 동작에 따라 새로운 트랜잭션을 생성합니다.

격리 수준(isolation level)이나 타임아웃(timeout)과 같은 매개변수는 새로운 트랜잭션에만 적용되며, 이미 활성화된 트랜잭션에 참여하는 경우에는 무시됩니다.

또한, 모든 트랜잭션 정의 설정이 모든 트랜잭션 매니저에서 지원되는 것은 아닙니다. 적절한 트랜잭션 매니저 구현체는 지원되지 않는 설정이 사용될 경우 예외를 발생시켜야 합니다.

위 규칙의 예외는 read-only 플래그입니다. 명시적인 read-only 모드를 지원하지 않는 경우, 이 플래그는 무시되어야 합니다. 기본적으로 read-only 플래그는 잠재적인 최적화를 위한 힌트일 뿐입니다.

위와 같은 설명을 하고 있다.

 

하지만 여전히 비즈니스 로직에만 집중하는 것이 아닌 DB접근과 같은 다른 관심사의 업무를 수행해야 한다.

 

❤️ 선언적 트랜잭션(@Transactional)

개념

Transaction 관리를 별도의 어노테이션으로 분리하여 AOP로 횡단 관심사 처리를 진행하는 것이다.

이를 통해 프로그래밍 과정에서 트랜잭션으로 인한 코드 중복 문제, 소스코드 유지 보수 어려움의 문제를 해결할 수 있다.

 

사용

코드를 작성하는 과정에서 @Transactional을 입력하려고 하면 매번 두 개의 import를 선택할 수 있음을 느꼈을 것이다.

두 개는 무엇이 다르고 어떤 것을 선택해야 할까?

📊 Spring Transaction vs Jakarta Transaction 비교

구분	Spring Framework Transaction	Jakarta Transcation
어노테이션 패키지	org.springframework.transaction.annotation.Transactional	jakarta.transaction.Transactional
소속	Spring Framework	Jakarta EE (표준)
기반 기술	Spring 자체 추상화 + AOP	JTA (Java Transaction API)
트랜잭션 매니저	PlatformTransactionManager	JTA Transaction Manager
기본 롤백 정책	RuntimeException, Error 롤백	RuntimeException 롤백 (구현체 의존)
Checked Exception 롤백	기본 ❌ (옵션으로 가능)	기본 ❌ (rollbackOn으로 지정)
rollback 커스터마이징	rollbackFor, noRollbackFor	rollbackOn, dontRollbackOn
전파 옵션(Propagation)	REQUIRED, REQUIRES_NEW, NESTED 등 매우 다양	REQUIRED, REQUIRES_NEW 등 일부만
격리 수준(Isolation)	직접 설정 가능	직접 설정 불가
timeout 설정	가능	제한적
readOnly 옵션	있음 (최적화 힌트)	없음
AOP 기반 동작	O (프록시 기반)	컨테이너 관리
ThreadLocal 사용	사용 (동기 트랜잭션)	구현체 의존
Reactive 지원	O (ReactiveTransactionManager)	X
주 사용 환경	Spring Boot / Spring 기반 앱	Jakarta EE 서버 (WildFly 등)
세밀한 제어	매우 강함	비교적 단순

Spring or Spring boot로 개발을 진행하는 환경이라면 Spring Framework Transaction을 선택하여 사용하자.

 

org.springframework.transaction.annotation.Transactional

클래스 주석 번역문

개별 메서드 또는 클래스에 트랜잭션 속성을 설명합니다.

이 어노테이션이 클래스 수준에 선언되면, 해당 클래스와 그 하위 클래스의 모든 메서드에 기본값으로 적용됩니다. 단, 클래스 계층 구조에서 상위(조상) 클래스에는 적용되지 않습니다. 상속된 메서드가 하위 클래스 수준의 어노테이션에 참여하려면 해당 메서드를 하위 클래스에서 다시 선언해야 합니다. 메서드 가시성 제약에 대한 자세한 내용은 레퍼런스 매뉴얼의 Transaction Management 섹션을 참고하십시오.

이 어노테이션은 일반적으로 Spring의 org.springframework.transaction.interceptor.RuleBasedTransactionAttribute 클래스와 직접적으로 비교할 수 있습니다. 실제로 AnnotationTransactionAttributeSource는 이 어노테이션의 속성들을 RuleBasedTransactionAttribute의 속성으로 직접 변환합니다. 따라서 Spring의 트랜잭션 지원 코드는 어노테이션 자체를 알 필요가 없습니다.



속성 의미 (Attribute Semantics)

이 어노테이션에 사용자 정의 롤백 규칙이 구성되지 않은 경우, 트랜잭션은 RuntimeException과 Error에 대해서는 롤백되지만, 체크 예외(checked exception)에 대해서는 롤백되지 않습니다.

롤백 규칙은 특정 예외가 발생했을 때 트랜잭션을 롤백할지 여부를 결정하며, 타입 또는 패턴을 기반으로 합니다. 사용자 정의 규칙은 rollbackFor / noRollbackFor 및 rollbackForClassName / noRollbackForClassName을 통해 설정할 수 있으며, 각각 타입 기반 또는 패턴 기반으로 규칙을 지정할 수 있습니다.

예외 타입을 사용하여 롤백 규칙을 정의한 경우(예: rollbackFor), 해당 타입은 발생한 예외의 타입과 비교하여 매칭됩니다. 구체적으로, 설정된 예외 타입 C가 있을 때, 발생한 예외 타입 T가 C와 동일하거나 C의 하위 클래스라면 매칭된 것으로 간주됩니다. 이는 타입 안정성을 제공하며, 패턴 사용 시 발생할 수 있는 의도치 않은 매칭을 방지합니다. 예를 들어 jakarta.servlet.ServletException.class를 지정하면, jakarta.servlet.ServletException 및 그 하위 클래스에 대해서만 매칭됩니다.

예외 패턴을 사용하여 롤백 규칙을 정의한 경우, 패턴은 예외 타입(반드시 Throwable의 하위 클래스여야 함)의 전체 클래스 이름(FQCN)이거나 그 일부 문자열일 수 있습니다. 현재는 와일드카드 지원이 없습니다. 예를 들어 "jakarta.servlet.ServletException" 또는 "ServletException"이라는 값은 jakarta.servlet.ServletException 및 그 하위 클래스와 매칭됩니다.

주의: 패턴을 얼마나 구체적으로 지정할지, 그리고 패키지 정보를 포함할지(필수는 아님)를 신중히 고려해야 합니다. 예를 들어 "Exception"은 거의 모든 예외와 매칭되므로 다른 규칙을 가릴 가능성이 큽니다. 만약 모든 체크 예외에 대한 규칙을 정의하려는 목적이라면 "java.lang.Exception"을 사용하는 것이 적절합니다. "BaseBusinessException"처럼 고유한 이름을 가진 예외라면 전체 클래스 이름을 사용할 필요가 없을 수 있습니다.

또한 패턴 기반으로 정의된 롤백 규칙은 이름이 유사한 예외나 중첩 클래스에 대해 의도치 않은 매칭을 일으킬 수 있습니다. 이는 발생한 예외의 이름에 설정된 예외 패턴 문자열이 포함되어 있으면 매칭된 것으로 간주되기 때문입니다. 예를 들어 "com.example.CustomException"이라는 규칙이 설정된 경우, 다음과 같은 예외에도 매칭됩니다:

com.example.CustomExceptionV2 (같은 패키지에 있으나 이름에 접미사가 추가된 경우) com.example.CustomException$AnotherException (CustomException 내부에 선언된 중첩 클래스)

이 어노테이션의 다른 속성 의미에 대한 구체적인 정보는 TransactionDefinition 및 org.springframework.transaction.interceptor.TransactionAttribute의 Javadoc을 참고하십시오.



트랜잭션 관리 (Transaction Management)

이 어노테이션은 일반적으로 org.springframework.transaction.PlatformTransactionManager에 의해 관리되는 스레드 바인딩(thread-bound) 트랜잭션과 함께 동작하며, 현재 실행 스레드 내의 모든 데이터 접근 작업에 트랜잭션을 노출합니다. 단, 이 트랜잭션은 해당 메서드 내부에서 새롭게 시작된 스레드로는 전파되지 않습니다.

또는 이 어노테이션은 org.springframework.transaction.ReactiveTransactionManager에 의해 관리되는 리액티브 트랜잭션을 구분하는 데 사용될 수 있습니다. 이 경우 ThreadLocal 변수가 아니라 Reactor Context를 사용합니다. 따라서 모든 참여 데이터 접근 작업은 동일한 리액티브 파이프라인 내에서, 동일한 Reactor Context 안에서 실행되어야 합니다.

참고: ReactiveTransactionManager와 함께 구성된 경우, 모든 트랜잭션이 선언된 메서드는 리액티브 파이프라인을 반환해야 합니다. void 메서드나 일반 반환 타입을 사용하는 경우에는 일반적인 PlatformTransactionManager와 연결되어야 하며, 예를 들어 transactionManager()를 통해 설정해야 합니다.

메서드

public @interface Transactional {

    // 트랜잭션 매니저 이름 지정 (transactionManager의 별칭)
    // 여러 TransactionManager가 있을 때 특정 매니저를 선택하기 위해 사용
    String value() default "";

    // 사용할 PlatformTransactionManager Bean 이름 지정
    // 멀티 데이터소스 환경에서 사용
    String transactionManager() default "";

    // 트랜잭션에 라벨(태그)을 부여
    // 모니터링/추적용 메타데이터이며 트랜잭션 동작에는 영향 없음
    String[] label() default {};

    // 트랜잭션 전파 옵션 설정
    // 기존 트랜잭션이 있을 때 어떻게 동작할지 결정 (기본: REQUIRED)
    Propagation propagation() default Propagation.REQUIRED;

    // 트랜잭션 격리 수준 설정
    // 동시성 제어를 위한 설정이며 기본값은 DB 기본값 사용
    Isolation isolation() default Isolation.DEFAULT;

    // 트랜잭션 타임아웃(초 단위)
    // 지정 시간 초과 시 롤백 (기본값은 트랜잭션 매니저 기본값 사용)
    int timeout() default TransactionDefinition.TIMEOUT_DEFAULT;

    // 타임아웃을 문자열로 지정
    // SpEL 또는 프로퍼티 값 사용 가능
    String timeoutString() default "";

    // 읽기 전용 트랜잭션 여부
    // 성능 최적화를 위한 힌트 (강제 제한은 아님)
    boolean readOnly() default false;

    // 지정한 예외 타입 발생 시 롤백
    // 해당 타입 및 하위 클래스까지 적용
    Class<? extends Throwable>[] rollbackFor() default {};

    // 예외 클래스 이름(문자열 패턴) 기반 롤백 지정
    // 이름에 해당 문자열이 포함되면 매칭됨 (와일드카드 없음)
    String[] rollbackForClassName() default {};

    // 지정한 예외 타입 발생 시 롤백하지 않음
    // RuntimeException이라도 커밋하도록 설정 가능
    Class<? extends Throwable>[] noRollbackFor() default {};

    // 예외 클래스 이름(문자열 패턴) 기반 롤백 제외 지정
    String[] noRollbackForClassName() default {};
}

트랜잭션 격리 수준 (Isolation Level)

동시에 실행되는 트랜잭션 간의 데이터 접근 허용 범위를 결정하는 설정

트랜잭션 이상 현상

Dirty Read	커밋되지 않은 데이터를 읽음
Non-repeatable Read	같은 데이터를 두 번 조회했는데 값이 달라짐
Phantom Read	같은 조건으로 조회했는데 행 개수가 달라짐

1. DEFAULT

• 데이터베이스에서 설정된 기본 격리 수준을 따름
• Spring은 관여하지 않음
• 보통 DB 기본값 사용

참고:

• MySQL(InnoDB) 기본: REPEATABLE READ
• Oracle 기본: READ COMMITTED

2. READ_UNCOMMITTED

• 커밋되지 않은 데이터 조회 가능
• Dirty Read 허용
• 가장 낮은 격리 수준
• 정합성 낮음, 동시성 높음
• 대부분의 상용 DB에서는 사실상 READ_COMMITTED처럼 동작

3. READ_COMMITTED

• 커밋된 데이터만 조회 가능
• Dirty Read 방지
• Non-repeatable Read, Phantom Read는 발생 가능
• 실무에서 가장 많이 사용

4. REPEATABLE_READ

• 동일 트랜잭션 내에서 같은 데이터 조회 시 항상 동일 값 보장
• Dirty Read, Non-repeatable Read 방지
• Phantom Read는 DB 구현에 따라 발생 가능
• MySQL 기본 격리 수준

5. SERIALIZABLE

• 가장 높은 격리 수준
• 모든 트랜잭션을 순차 실행처럼 보장
• Dirty / Non-repeatable / Phantom Read 모두 방지
• 동시성 매우 낮음
• 성능 저하 가능성 큼
• 금융/정산 등 강한 정합성이 필요한 경우 사용

Spring에서의 특징

• isolation 옵션은 "새로운 트랜잭션 생성 시에만" 적용
• 기존 트랜잭션에 참여하는 경우 무시됨
• DB가 지원하지 않는 격리 수준이면 예외 발생 가능

트랜잭션 전파 옵션 (Propagation)

기존 트랜잭션 존재 여부에 따라 현재 메서드가 어떻게 동작할지 결정

1. REQUIRED (기본값)

• 기존 트랜잭션이 있으면 참여
• 없으면 새로 생성
• 가장 많이 사용되는 옵션

2. SUPPORTS

• 기존 트랜잭션이 있으면 참여
• 없으면 트랜잭션 없이 실행
• 조회용 메서드에 자주 사용

3. REQUIRES_NEW

• 항상 새로운 트랜잭션 생성
• 기존 트랜잭션은 잠시 중단(Suspend)
• 독립적인 커밋/롤백 필요할 때 사용
• 예: 로그 저장, 감사 기록

4. MANDATORY

• 기존 트랜잭션이 반드시 있어야 함
• 없으면 예외 발생
• 단독 실행이 허용되지 않는 경우 사용

5. NOT_SUPPORTED

• 트랜잭션 없이 실행
• 기존 트랜잭션 있으면 중단
• 락을 피하고 싶은 대량 조회 등에 사용

6. NEVER

• 트랜잭션이 존재하면 예외 발생
• 완전 비트랜잭션 환경 강제

7. NESTED

• 기존 트랜잭션 내부에 중첩 트랜잭션 생성
• Savepoint 기반 동작
• 부모 롤백 시 자식도 롤백
• 자식 롤백은 부모에 영향 없음
• DataSourceTransactionManager에서만 지원
• JPA는 기본적으로 지원하지 않음

 

출처

https://docs.spring.io/spring-framework/docs/4.2.x/spring-framework-reference/html/transaction.html

https://velog.io/@betterfuture4/Spring-Transactional-%EC%B4%9D%EC%A0%95%EB%A6%AC

https://adjh54.tistory.com/378

https://docs.spring.io/spring-framework/reference/data-access/transaction/declarative/annotations.html#transaction-declarative-annotations-method-visibility