Transaction Propagation

이 섹션은 Spring에서의 transaction propagation의 일부 시맨틱스를 설명합니다. 이 섹션은 transaction propagation에 대한 올바른 소개가 아닙니다. 오히려, Spring에서의 transaction propagation과 관련된 시맨틱스의 일부를 자세히 설명합니다.

Spring이 관리하는 transaction에서는 물리적 트랜잭션과 논리적 트랜잭션의 차이와 propagation 설정이 이 차이에 어떻게 적용되는지에 유의해야 합니다.

Understanding PROPAGATION_REQUIRED

PROPAGATION_REQUIRED는 아직 트랜잭션이 존재하지 않는 경우 현재 스코프에 대해 로컬하게 또는 더 큰 스코프에 대해 정의된 기존의 'outer' 트랜잭션에 참여하는 방식으로 물리적 트랜잭션을 강제합니다. 이는 동일한 스레드 내의 일반적인 호출 스택 구성 (예를 들어, 여러 리포지토리 메서드에 위임하는 서비스 파사드에서 모든 underlying 리소스가 서비스 수준 트랜잭션에 참여해야 하는 경우)에 적합한 기본값입니다.

기본적으로, 참여하는 트랜잭션은 outer 스코프의 특성에 합류하며, 로컬 격리 수준, 타임아웃 값, 또는 읽기 전용 플래그(있는 경우)를 조용히 무시합니다. 기존 트랜잭션에 참여할 때 격리 수준이 다른 경우 격리 수준 선언이 거부되도록 하려면 트랜잭션 매니저에서 validateExistingTransactions 플래그를 true로 전환하는 것을 고려하십시오. 이 non-lenient 모드는 읽기 전용 불일치(즉, 읽기 전용 outer 스코프에 참여하려는 inner 읽기-쓰기 트랜잭션)도 거부합니다.

propagation 설정이 PROPAGATION_REQUIRED인 경우, 이 설정이 적용된 각 메서드마다 논리적 트랜잭션 스코프가 생성됩니다. 이러한 각 논리적 트랜잭션 스코프는 rollback-only 상태를 개별적으로 결정할 수 있으며, outer 트랜잭션 스코프는 inner 트랜잭션 스코프와 논리적으로 독립적입니다.

표준 PROPAGATION_REQUIRED behavior의 경우, 이러한 모든 스코프는 동일한 물리적 트랜잭션에 매핑됩니다. 따라서 inner 트랜잭션 스코프에서 설정된 rollback-only 마커는 outer 트랜잭션이 실제로 커밋할 수 있는 가능성에 영향을 줍니다.

그러나 inner 트랜잭션 스코프가 rollback-only 마커를 설정한 경우, outer 트랜잭션은 자체적으로 롤백을 결정하지 않았으므로(내부 트랜잭션 스코프에 의해 조용히 trigger된) 롤백은 예상치 못한 것입니다. 그 시점에 해당하는 UnexpectedRollbackException이 발생합니다.

이는 트랜잭션의 호출자가 실제로 커밋이 수행되지 않았음에도 커밋이 수행되었다고 오도될 수 없도록 하기 위한 expected behavior입니다. 따라서 outer 호출자가 알지 못하는 inner 트랜잭션이 트랜잭션을 조용히 rollback-only로 표시한 경우에도 outer 호출자는 여전히 커밋을 호출합니다. 롤백이 대신 수행되었음을 명확히 나타내기 위해 outer 호출자는 UnexpectedRollbackException을 수신해야 합니다.

Understanding PROPAGATION_REQUIRES_NEW

PROPAGATION_REQUIRES_NEW는 PROPAGATION_REQUIRED와 달리, 영향을 받는 각 트랜잭션 스코프에 대해 항상 독립적인 물리적 트랜잭션을 사용하며, outer 스코프에 대한 기존 트랜잭션에 절대 참여하지 않습니다. 이러한 구성에서 underlying 리소스 트랜잭션은 서로 다르며, 따라서 outer 트랜잭션이 inner 트랜잭션의 롤백 상태에 영향을 받지 않고 inner 트랜잭션의 락은 완료 직후 즉시 해제되면서, 각각 독립적으로 커밋 또는 롤백할 수 있습니다.

이러한 독립적인 inner 트랜잭션은 자체 격리 수준, 타임아웃 및 읽기 전용 설정을 선언할 수도 있으며, outer 트랜잭션의 특성을 상속하지 않습니다.

outer 트랜잭션에 attach된 리소스는 inner 트랜잭션이 새로운 데이터베이스 커넥션과 같은 자체 리소스를 획득하는 동안 outer 트랜잭션에 계속 bound된 상태로 남습니다. 이는 커넥션 풀의 고갈로 이어질 수 있으며, 여러 스레드가 active outer 트랜잭션을 가지고 inner 트랜잭션을 위해 새로운 커넥션을 획득하기를 기다리는 동안 풀이 더 이상 그러한 inner 커넥션을 제공할 수 없는 경우 잠재적으로 데드락이 발생할 수 있습니다. 커넥션 풀이 적절히 사이징되어 concurrent 스레드 수보다 최소 1 이상 크지 않은 한 PROPAGATION_REQUIRES_NEW를 사용하지 마십시오.

Understanding PROPAGATION_NESTED

PROPAGATION_NESTED는 롤백할 수 있는 여러 savepoint를 가진 단일 물리적 트랜잭션을 사용합니다. 이러한 partial 롤백은 inner 트랜잭션 스코프가 자신의 스코프에 대한 롤백을 trigger하도록 허용하며, 일부 operation이 롤백되었음에도 outer 트랜잭션이 물리적 트랜잭션을 계속할 수 있도록 합니다.

이 설정은 일반적으로 JDBC savepoint에 매핑되므로 JDBC 리소스 트랜잭션에서만 동작합니다. Spring의 DataSourceTransactionManager를 참조하십시오.