[Spring] Spring @Transactional 세부 설정

🔹 Spring Transaction의 세부 설정

Spring에서 @Transactional 세부 설정할 때, 지원하는 주요 속성은 다음과 같다.

• 전파 속성 (Propagation)
• 격리 수준 (Isolation Level)
• 읽기 전용 여부 (Read-Only Flag)
• 제한 시간 (Timeout)
• 트랜잭션 롤백 예외 설정 (Rollback For, No Rollback For)

 

[ 전파 속성 (Propagation) ]

Spring이 제공하는 선언적 트랜잭션(@Transactional)의 장점 중 하나는 여러 트랜잭션의 적용 범위를 하나로 묶어, 큰 트랜잭션 경계를 만들 수 있다는 점이다.

트랜잭션이 어떻게 동작할지 결정하려면 전파 속성 (Propagation)을 설정해야 하며, 이를 통해 새로운 트랜잭션을 시작할지, 기존 트랜잭션에 참여할지 등을 제어할 수 있다.

 

[ 전파 속성 목록 ]

• REQUIRED
• SUPPORTS
• MANDATORY
• REQUIRES_NEW
• NOT_SUPPORTED
• NEVER
• NESTED

◽ REQUIRED (기본 전파 속성)

• REQUIRED는 트랜잭션이 이미 존재하면 해당 트랜잭션을 재사용하고, 없으면 새로운 트랜잭션을 생성하는 방식이다.
• 가장 일반적이며 자연스러운 트랜잭션 전파 방식이며, 모든 트랜잭션 매니저가 지원한다.
• 하나의 트랜잭션이 시작된 후, 다른 트랜잭션 경계가 설정된 메서드를 호출하면 자동으로 동일한 트랜잭션에 묶인다.

◽ SUPPORTS

• SUPPORTS는 트랜잭션이 이미 시작된 경우 참여하지만, 그렇지 않으면 트랜잭션 없이 실행된다.
• 트랜잭션이 없어도 데이터베이스 연결(Connection)이나 Hibernate의 세션(Session)은 공유할 수 있다.
• 중요한 작업에서는 사용하지 않는 것이 좋으며, 트랜잭션이 필수가 아닌 경우에만 적절하다.

◽ MANDATORY

• MANDATORY는 반드시 기존 트랜잭션이 존재해야 하며, 없으면 예외(TransactionRequiredException)가 발생한다.
• 즉, 새로운 트랜잭션을 생성하지 않고, 반드시 기존 트랜잭션 내에서만 실행된다.
• 부모 트랜잭션이 필수적인 경우에 사용하며, 독립적인 트랜잭션 실행이 허용되지 않는 상황에 적합하다.

◽ REQUIRES_NEW

• REQUIRES_NEW는 항상 새로운 트랜잭션을 생성하며, 기존 트랜잭션이 존재하는 경우 이를 일시적으로 보류(suspend)한다.
• 즉, 부모 트랜잭션과 별개의 트랜잭션으로 실행되며, 기존 트랜잭션과 독립적인 커밋/롤백이 가능하다.
• JTA(Java Transaction API) 트랜잭션 매니저를 사용할 경우, 트랜잭션 보류 기능이 지원되어야 한다.

◽ NOT_SUPPORTED

• NOT_SUPPORTED는 현재 진행 중인 트랜잭션이 있다면, 이를 보류(suspend)시키고, 트랜잭션 없이 실행한다.
• 트랜잭션이 필요 없는 작업(대량 데이터 조회 등)에 적합하며, 트랜잭션이 불필요한 서비스 레이어에서 사용하면 성능 최적화가 가능하다.

◽ NEVER

• NEVER는 현재 진행 중인 트랜잭션이 존재하면 예외(IllegalTransactionStateException)를 발생시킨다.
• 트랜잭션이 절대 포함되면 한 되는 작업(로깅, 모니터링, 단순 조회 등)에서 사용한다.

◽ NESTED

• NESTED는 현재 진행 중인 트랜잭션이 있으면 그 내부에서 중첩 트랜잭션을 시작하는 방식이다.
• 중첩 트랜잭션은 부모 트랜잭션의 커밋과 롤백에 영향을 받지만, 자신만 롤백할 수도 있으며 부모 트랜잭션을 강제로 커밋하거나 롤백시키지 않는다.
  
  • REQUIRES_NEW와의; 차이점 
  • REQUIRES_NEW는 완전히 새로운 트랜잭션을 생성하여 부모 트랜잭션과 독립적으로 실행된다.
  • 반면, NESTED는 부모 트랜잭션 내에서 실행되며, 부모 트랜잭션의 영향을 받지만, 자신만 롤백할 수도 있다.

예를 들어, 중요한 작업을 수행하면서 로그 데이터를 함께 저장해야 하는 경우를 가정해 보자.

• 메인 트랜잭션에서 중요한 작업을 수행하고, 중첩 트랜잭션에서 로그를 저장한다.
• 만약 로그 저장이 실패하더라도, 메인 작업은 그대로 진행되어야 한다.
• 하지만, 핵심 작업이 실패하면, 저장된 로그도 함께 롤백되어야 한다

@Service
public class TransactionService {

    @Transactional(propagation = Propagation.NESTED)
    public void saveLog() {
        // 로그 저장 로직 (이 작업만 롤백될 수 있음)
    }

    @Transactional
    public void processImportantTask() {
        // 중요한 작업 수행
        saveLog();  // 중첩 트랜잭션 실행
    }
}

이런 방식으로 NESTED를 사용한다면,

• 메인 작업이 실패하면, 중첩 트랜잭션(로그 저장)도 롤백된다.
• 반면, 로그 저장이 실패해도, 메인 작업은 정상적으로 진행된다.

NESTED 전파 속성을 사용하려면, JDBC 3.0의 저장 포인트(Savepoint)를 지원하는 트랜잭션 매니저가 필요하다.

즉, 모든 트랜잭션 매니저에서 지원되는 것은 아니므로, 사용 전에 환경을 확인해야 한다.

 

[ 적용 가능 환경 ]

• DataSourceTransactionManager 사용 (JDBC 드라이버가 Savepoint 기능을 지원해야 함)
• JTA(Java Transaction API) 트랜잭션 매니저를 사용하는 일부 WAS(Web Application Server)

 

선언적 트랜잭션에서는 @Transactional 어노테이션의 propagation 앨리먼트로 원하는 전파 속성을 지정할 수 있으며, 기본값은 REQUIRED로 설정되어 있다.

또한, Spring은 7가지 전파 속성을 지원하지만, 해당 속성을 지원하지 않는 트랜잭션 매니저나 데이터 액세스 기술이 있을 수 있으므로, 전파 속성 변경이 필요한 경우 사용 중인 트랜잭션 매니저나 기술에 대해 별도의 설정이 필요한지 확인해야 한다.

 

[ 격리 수준 (Isolation Level) ]

트랜잭션 격리 수준은 여러 트랜잭션이 동시에 실행될 때, 각 트랜잭션의 작업 결과가 다른 트랜잭션에 어떻게 노출될지 결정하는 설정이다. 격리 수준이 높을수록 데이터의 일관성이 보장되지만, 동시성 처리 성능이 저하될 수 있다.

 

[ 격리 수준 목록 ]

• DEFAULT
• READ_UNCOMMITTED
• READ_COMMITTED
• REPEATABLE_READ
• SERIALIZABLE

◽ DEFAULT

• DEFAULT는 사용 중인 데이터 액세스 기술이나 DB 드라이버의 기본 격리 수준을 따른다.
• 일반적으로 DB의 기본 격리 수준은 READ_COMMITTED이지만, 일부 DB에서는 기본 설정 값이 다를  수 있다.
• 따라서 DEFAULT를 사용할 경우, DB 드라이버 및 DBMS의 기본 격리 수준을 반드시 확인해야 한다.

◽ READ_UNCOMMITTED

• READ_UNCOMMITTED는 가장 낮은 격리 수준으로, 트랜잭션이 커밋되기 전에 발생한 변경 사항도 다른 트랜잭션에서 조회될 수 있다.
• 즉, Dirty Read(더티 리드) 문제가 발생할 수 있어 데이터 일관성이 보장되지 않는다.
• 하지만, 격리 수준이 낮을수록 성능이 향상되므로, 데이터 정합성보다 성능이 중요한 경우에 의도적으로 사용되기도 한다.

◽ READ_COMMITTED

• READ_COMMITTED는 가장 많이 사용되는 격리 수준으로, 커밋이 완료된 데이터만 읽을 수 있도록 보장한다.
• 즉, 다른 트랜잭션이 아직 커밋하지 않은 데이터를 조회할 수 없다.
• 하지만 트랜잭션이 같은 데이터를 두 번 조회할 때, 그 사이에 다른 트랜잭션이 데이터를 변경하면 서로 다른 값을 읽을 수도 있다. 이러한 현상을 Non-Repeatable Read(비반복 읽기) 문제라고 한다.
• Spring의 기본 격리 수준은 DEFAULT이지만, 대부분의 DBMS는 READ_COMMITTED를 기본적으로 사용하기 때문에 일반적으로 가장 널리 쓰인다.

◽ REPEATABLE_READ

• REPEATABLE_READ는 하나의 트랜잭션이 조회한 데이터(row)를 다른 트랜잭션이 수정할 수 없도록 보장한다.
• 즉, 트랜잭션이 진행되는 동안 동일한 데이터를 조회하면 항상 동일한 값을 반환받는다.
• 하지만 새로운 데이터(row)를 추가(INSERT)하는 것은 허용된다.
• 따라서, SELECT문을 통해 특정 조건에 맞는 데이터를 조회했을 때, 트랜잭션이 끝나기 전에 새로운 데이터가 추가되면 이를 발견할 수 있다. 이러한 현상을 Phantom Read(팬텀 리드) 문제라고 한다.

◽ SERIALIZABLE

• SERIALIZABLE는 가장 강력한 트랜잭션 격리 수준으로, 모든 트랜잭션을 순차적으로 실행하도록 강제한다.
• 즉, 하나의 트랜잭션이 완료되기 전까지 다른 트랜잭션은 해당 데이터를 읽거나 수정할 수 없다.
• 이 격리 수준에서는 동일한 데이터를 조회하는 트랜잭션이 직렬화되어 실행되므로, Dirty Read, Non-Repeatable Read, Phantom Read 문제가 모두 방지된다.
• 하지만, 동시성 처리 성능이 크게 저하될 수 있어, 극도로 높은 데이터 정합성이 필요한 경우에만 사용해야 한다.

 

선언적 트랜잭션에서는 @Transactional 어노테이션의 isolation 앨리먼트로 원하는 격리 수준을 지정할 수 있으며, 기본 값은 DEFAULT로 설정되어 있다.

@Transactional(isolation = Isolation.DEFAULT)  
@Transactional(isolation = Isolation.READ_COMMITTED)

 

[ 읽기 전용 여부 (Read-Only Flag) ]

@Transactional(readOnly=true)

Spring에서는 트랜잭션을 다음  두 가지 목적으로 읽기 전용(Read-Only)으로 설정할 수 있다.

• 성능 최적화 : 불필요한 트랜잭션 리소스를 최소화하여 성능을 향상시킨다.
• 쓰기 방지 : 의도하지 않은 INSERT, UPDATE, DELETE 작업을 방지한다.

트랜잭션을 읽기 전용으로 설정하면, 해당 정보가 트랜잭션 매니저에게 전달되며, 트랜잭션 매니저는 이를 기반으로 최적화된 작업을 수행한다.

다만, 일부 트랜잭션 매니저는 읽기 전용 설정을 무시하고 쓰기 작업을 허용할 수 있으므로 주의해야 한다. 일반적으로, 읽기 전용 트랜잭션 내에서 INSERT, UPDATE, DELETE 작업이 수행되면 예외가 발생한다.

 

[ 제한 시간 (Timeout) ]

@Transactional(timeout=10)

timeout 속성을 이용하면 트랜잭션에 제한 시간을 지정할 수 있다. 값은 초 단위의 정수(int)로 지정할 수 있다. 만약 문자열로 지정하기를 원한다면 timeoutString을 사용하면 된다.

제한 시간을 별도로 지정하지 않으면, 기본적으로 트랜잭션 시스템의 제한 시간이 적용된다. 또한, 트랜잭션 매니저에서 이 기능을 지원하지 않는 경우, 제한 시간을 설정하면 예외가 발생할 수 있다.

 

[ 트랜잭션 롤백 예외 설정 (Rollback For, No Rollback For) ]

// MyException 발생 시 트랜잭션 롤백
@Transactional(rollbackFor=MyException.class)
// MyException 발생 시 트랜잭션 롤백 X
@Transactional(noRollbackFor=MyException.class)

선언적 트랜잭션에서는 기본적으로 런타임 예외가 발생하면 롤백하고, 예외가 발생하지 않거나 체크 예외가 발생하면 커밋한다.

여기서 체크 예외를 커밋 대상으로 삼은 이유는, 체크 예외가 일반적으로 예외적인 상황보다는 비즈니스 로직에서의 결과를 나타내는 데 사용되기 때문이다.

Spring에서는 데이터 액세스 관련 예외를 런타임 예외로 전환하여 처리하기 때문에, 기본적으로 런타임 예외만 롤백 대상으로 설정된다.

하지만 트랜잭션의 롤백/커밋 동작 방식의 변경하려면 설정을 통해 동작 방식을 수정할 수 있다.

예를 들어, 커밋 대상으로 삼고 싶은 체크 예외나 클래스를 지정하려면 rollbackFor 또는 rollbackForClassName을 사용하고, 롤백 대상인 런타임 예외를 커밋 대상으로 변경하려면 noRollbackFor 또는 noRollbackForClassName을 사용한다.

 

 

위에서 설명한 모든 트랜잭션 속성들은 각 트랜잭션 경계 설정에서 지정할 수 있다.

하지만 대부분의 경우, readOnly 속성만 활용하고 나머지는 기본 값으로 사용하는 경우가 많다. 세밀한 속성은 DBMS나 WAS의 트랜잭션 매니저 설정을 통해 관리할 수 있기 때문이다.

 

 

 

 

 

📃 reference

• https://mangkyu.tistory.com/169
• https://innovation123.tistory.com/165