Spring Transaction 에 대한 이해

📌 들어가며 

코드리뷰를 진행하다 보면 항상 나오는 얘기 중 하나가 바로 '트랜잭션 관리를 어떻게 할것인가' 에 대한 내용입니다.

그만큼 Exception이 발생했을 때 어떻게 할 것인가에 대한 내용이 중요한 만큼 이에 대한 대처 중 하나인 Transaction에 대해 정리해 보도록 하겠습니다. 

---

📌 Transaction 의 정의

 트랜잭션은 데이터베이스의 상태를 변경하는 작업 또는 한번에 수행되어야 하는 연산들을 뜻합니다.

즉, 병행 제어 시 처리되는 작업의 논리적 단위입니다.

 

Transaction은 하나의 흐름으로 하나의 실행이 성공하거나 실패하면 모든 연산들을 동일하게 처리합니다.

A, B, C의 연산을 한 묶음이라고 할 때 A는 정상 작동 됐지만,

B가 실패한다면 A의 작업 이력도 이전으로 돌립니다.

 

모든 작업이 성공한다면 완료 작업 상태를 모두 반영하고, 이것을 Commit이라고 합니다.

반면, 하나라도 실패하게 된다면 모든 사항을 폐기하고, 이것을 Rollback이라고 합니다.

---

📌 Transaction 의 4가지 성질

트랜잭션은 4가지의 성질을 가지고 있습니다.

 

이를 ACID 라고 하는데 해당 성질은 아래와 같습니다.

 

Atomicity 원자성

: 한 트랜잭션 내의 실행 작업은 하나의 단위로 처리한다. / 모두 성공 또는 모두 실패

Consistency 일관성

: 트랜잭션은 일관성 있는 데이터베이스의 상태를 유지한다.

➡️ 하나의 동작이 정상적인 흐름을 일관되게 유지하여야 한다는 원칙입니다.

Isolation 독립성

: 동시에 실행되는 트랜잭션들이 서로 영향을 미치지 않도록 독립되어야 한다.

➡️ 격리성 이라고도 하는 이 성질은 하나의 동작 중 다른 트랜잭션이 개입하여 데이터 변경이 일어나서는

안된다는 것을 의미합니다.  (한 동작이 독립적으로 처리)

Durability 영속성

: 트랜잭션이 성공적으로 마치면 결과가 항상 저장되어야 한다.

➡️ 트랜잭션의 동작이 성공 후 Commit 되게 된다면 이는 데이터베이스에 영원히 반영되어야 한다는 원칙입니다.

 

---

📌 TransactionManager 의 종류

✔️ DataSourceTransactionManager

: JDBC 및 MyBatis 등의 JDBC 기반 라이브러리로 데이터베이스에 접근하는 경우에 이용합니다.

이 트랜잭션 매니저를 사용하려면 트랜잭션을 적용할 DataSource가 스프링의 빈으로 등록되어야 합니다. 

현재 제가 다니고 있는 회사 대부분의 서브 도메인이 이 방식의 TransactionManager를 사용하고 있습니다.

 

✔️ HibernateTransactionManager

: 하이버네이트를 이용해 데이터베이스에 접근하는 경우에 이용합니다.

 

✔️ JpaTransactionManager

: JPA로 데이터베이스에 접근하는 경우에 이용합니다.

JpaTransactionManager는 LocalContainerEntityManagerFactoryBean타입의 빈을 등록해줘야합니다.

✔️ JtaTransactionManager

: 하나 이상의 DB 나 글로벌 트랜잭션을 적용하려면 JTA 이용할 수 있습니다.

JTA는 여러 개의 트랜잭션 리소스(DB, JMS 등)에 대한 작업을 하나의 트랜잭션으로 묶을 수 있고,

여러 대의 서버에 분산되어 진행되는 작업을 트랜잭션으로 연결해주기도 합니다.

 

 

DB가 하나라면 트랜잭션 매니저 또한 하나만 등록되어야 하고,
여러개라도 JTA를 이용한 글로벌 트랙잭션을 적용할것이라면 JtaTransactionManager 하나만 등록되어야 합니다.

독립된 두 개 이상의 DB라면 DataSource도 두 개가 등록되므로,

DB 수에 따른 트랜잭션 매니저를 등록할 수 있습니다.

 

한 개의 서브 도메인에서 각기 다른 MySQL, Oracle 두 가지 DB에 접근이 필요할 경우

이중 Datasource를 사용하면서 트랜잭션 매니저 또한 두 개를 등록하게 됩니다.

 

---

📌 @Transactional

Spring에서는 트랜잭션이 적용될 타깃 인터페이스나 클래스, 메소드 등에 @Transactional 어노테이션을 부여하여,

트랜잭션 대상으로 지정하고 트랜잭션의 속성을 제공합니다.

 

즉, 트랜잭션을 적용하고자 하는 곳에 @Transactional 을 붙이면 적용된다는 의미입니다.

@Transactional의 정의를 보면 아래와 같습니다.

 

@Target(value={TYPE,METHOD})
 @Retention(value=RUNTIME)
 @Inherited
 @Documented
public @interface Transactional {}

 

Transactional Annotation은 Target이 TYPE과 METHOD 입니다.

즉, Class, interface, enum (TYPE) 이나, Method (METHOD) 에 적용할 수 있다는 의미입니다.

 

두 개의 Target에 동시에 붙일 수도 있는데요, 그 때에는 메소드에 붙은 애노테이션이 우선시되어 적용됩니다.

아래의 예시를 보면, readMember에는 readOnly 속성의 default값인 false가 무시되고

메소드 범위의 설정이 우선시 되어 readOnly가 true로 적용됩니다.

 

@Transactional
public interface MemberAnnotService {
    @Transactional(readOnly=true)
    void readMember(long memberId);

    void addMember(List<Member> members);
}

 

---

📌  Transaction Properties

선언적 트랜잭션은 6가지의 속성을 가지고 있습니다. 이러한

속성을 적당히 활용하여 로직상 필요에 의해 적정히 조정할 수 있어야 합니다.

 

일반적으로 트랜잭션의 경계를 설정할 때는

Propagation, Isolation, Timeout, ReadOnly 의 네 가지 트랜잭션 속성으로 트랜잭션마다 지정할 수 있으며

 

선언적 트랜잭션에서는 롤백과 커밋의 기준을 변경하기 위해

RollbackFor,  noRollbackFor 이라는 두 가지 추가 속성을 지정할 수 있습니다.

 

 

✔️ Propagation

: 트랜잭션 전파

 

트랜잭션을 시작하고, 혹은 트랜잭션을 수행하다가 다른 트랜잭션을 마주하면 어떻게 할까요?

그 처리 방식에 대한 설정입니다.

 

즉, 트랜잭션을 시작하거나 기존 트랜잭션에 참여하는 방법을 결정하는 속성입니다.

선언적 트랜잭션 방식의 장점은, 여러 트랜잭션 적용 범위를 묶어서 커다란 트랜잭션 경계를 만들 수 있습니다.

지정할 수 있는 속성은 아래와 같습니다.

 

✅ REQUIRED

: Default. 이미 시작된 트랜잭션이 있으면 참여하고, 없으면 새로 생성해 시작합니다.

대개 이 속성이면 충분하며, 자연스럽고 간단한 트랜잭션 전파 방식이지만 사용해보면 매우 강력하고 유용합니다.

하나의 트랜잭션이 시작된 후 다른 트랜잭션 경계가 설정된 메소드를 호출하면 자연스럽게 같은 트랜잭션으로 묶입니다.

 

✅ SUPPORT

: 이미 시작된 트랜잭션이 있으면 참여하고, 없으면 트랜잭션 없이 진행합니다.

 

✅ MANDATORY

: 이미 시작된 트랜잭션이 있으면 참여하고, 없으면 예외를 발생 시킵니다.

 

✅ REQUIRES_NEW

: 항상 새로운 트랜잭션을 시작하고, 이미 시작된 트랜잭션이 있으면 보류하고 생성합니다.

 

✅ NOT_SUPPORTED

: 트랜잭션을 전혀 사용하지 않고, 이미 시작된 트랜잭션이 있으면 보류합니다.

 

✅ NEVER

: 트랜잭션을 강제로 사용하지 않고, 이미 시작된 트랜잭션이 있으면 예외를 발생합니다.

트랜잭션을 지원하지 않는 설정입니다.

NOT_SUPPORTED와 비슷하지만, 예외를 발생시키는 점이 다릅니다.

 

✅ NESTED

: 이미 시작된 트랜잭션이 있으면 중첩 트랜잭션을 시작하고, 부모 트랜잭션에 영향을 주지 않습니다.

 

중첩 트랜잭션이라 트랜잭션 안에 트랜잭션을 만듭니다.

먼저 시작된 부모 트랜잭션의 커밋과 롤백에는 영향을 받지만 자신의 커밋과 롤백은 부모 트랜잭션에 영향을 주지 않죠.

 

예를 들어 로그 파일을 저장하는 로직은 메인 로직의 중첩 트랜잭션으로 진행 될 수 있는데,

로그 저장 로직에 문제가 있어도 메인 로직은 실행이 되어야 하기 때문에 영향을 주면 안되지만

메인 로직에 문제가 있어서 롤백을 하면 로그 저장 로직에도 영향을 줄 수 있어야 합니다.

 

// AOP - Advice 등록
DefaultTransactionAttribute defaultAttribute = new DefaultTransactionAttribute();
defaultAttribute.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);

// @Transactional
@Transactional(propagation = Propagation.PROPAGATION_REQUIRED)

 

 

✔️  Isolation

: 트랜잭션 격리 수준

 

트랜잭션 격리 수준은 동시에 여러 트랜잭션이 진행될 때,

트랜잭션의 작업 결과를 다른 트랜잭션에게 어떻게 노출할 것인지를 결정하는 기준입니다.

 

예를 들어 Transaction A가 읽기 작업을 할 때, Transaction B 가 접근할 수 있느냐,

혹은 Transaction A가 Commit 전일 때 Transaction B가 접근할 수 있느냐 를 설정합니다.

 

 

✅  DEFAULT

: 데이터 액세스 기술 또는 DB의 디폴트 설정을 따릅니다.

대부분의 DB는 READ_COMMITTED를 기본 격리 수준으로 갖지만,

데이터 액세스 기술이나 DB마다 다를 수 있기 때문에 DB나 드라이버 문서를 살펴볼 필요가 있습니다.

 

✅  READ_UNCOMMITTED (level 0)

: 커밋되지 않는 데이터에 대한 읽기 허용

- Dirty Read가 발생 가능
가장 낮은 격리 수준입니다. 하나의 트랜잭션이 커밋되기 전에 그 변화가 다른 트랜잭션에 그대로 노출되는 문제가 있습니다.

하지만 가장 빠르기 때문에 데이터의 일관성이 조금 떨어지더라도 성능을 극대화할 때 의도적으로 사용할 수 있습니다.

 

✅  READ_COMMITTED (level 1)

: 커밋된 데이터에 대한 읽기 허용

-Dirty Read 방지
가장 많이 사용되는 격리 수준으로, 커밋되지 않은 정보는 읽을 수 없습니다.

대신 하나의 트랜잭션이 읽은 로우를 다른 트랜잭션이 수정할 수 있습니다.

따라서, 트랜잭션이 같은 로우를 다시 읽었을 때 다른 내용일 수 있습니다.

 

✅  REPEATABLE_READ (level 2)

: 동일 필드에 대해 다중 접근 시 모두 동일한 결과를 보장

- Non-Repeatable Read 방지
하나의 트랜잭션이 읽은 로우를 다른 트랜잭션이 수정하는 것을 막지만, 새로운 로우를 추가하는 것은 제한하지 않습니다.

따라서 SELECT로 조건에 맞는 로우를 전부 가져오는 경우, 트랜잭션이 끝나기 전에 새로 추가된 로우가 발견될 수 있습니다.

 

✅  SERIALIZABLE (level 3)

: 읽기 작업에도 공유 잠금을 설정하게 되고, 다른 트랜잭션에서 변경하지 못함

트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 shared lock이 걸리므로

다른 사용자는 그 영역에 해당되는 데이터에 대한 수정 및 입력이 불가능합니다.

가장 안전한 격리수준이지만 가장 성능이 떨어지기 때문에 극단적으로 안전한 작업이 필요한 경우가 아니라면 자주 사용되지 않습니다.

 

// AOP - Advice 등록
DefaultTransactionAttribute defaultAttribute = new DefaultTransactionAttribute(TransactionDefinition.PROPAGATION_REQUIRED);
defaultAttribute.setIsolationLevel(1);

// @Transactional
@Transactional(isolation = Isolation.READ_UNCOMMITTED)

 

✔️  Timeout

: 트랜잭션 제한시간

 

초 단위로 제한 시간을 지정할 수 있습니다.

디폴트는 시스템의 제한 시간을 따르는 것입니다.

직접 지정하는 경우 이 기능을 지원하지 못하는 일부 트랜잭션 매니저는 예외를 발생할 수 있습니다.

 

 

✔️  ReadOnly

: 트랜잭션 읽기 전용

 

트랜잭션을 읽기 전용으로 설정할 수 있습니다.

성능을 최적화하기 위해 사용할 수도 있고,

특정 트랜잭션 작업 안에서 쓰기 작업이 일어나는 것을 의도적으로 방지하기 위해 사용할 수도 있습니다.

 

하지만 일부 트랜잭션 매니저의 경우 읽기 전용 속성을 무시할 수도 있으니 주의해야 합니다.

일반적으로 INSERT, UPDATE, DELETE 같은 쓰기 작업이 진행되면 예외가 발생합니다.

 

성능을 위해 queryservice 하위의 메서드에서 주로 사용하기도 합니다.

 

✔️ RollbackFor

RollbackFor, RollbackForClassName

트랜잭션 롤백 대상 지정

 

선언적 트랜잭션에서는 런타임 예외가 발생하면 롤백합니다.
예외가 발생하지 않거나 체크 예외가 발생하면 커밋합니다.

 

체크 예외를 커밋 대상으로 삼는 이유는 체크예외가 예외적인 상황에서 사용되기 보다는,

리턴값을 대신해서 비즈니스 적인 의미를 담은 결과를 돌려주는 용도로 많이 사용되기 때문입니다.

 

스프링에서는 데이터 액세스 기술의 예외는 런타임 예외(언체크 예외)로 전환되어서

던져지므로 런타임 예외만 롤백 대상으로 삼은 것입니다.

 

하지만 원한다면 기본 동작방식을 바꿀 수 있는데요.

바로 이 RollbackFor, RollbackForClassName속성을 이용해서 설정할 수 있습니다.

체크 예외지만 롤백 대상으로 삼아햐 하는 것이 있다면 이 속성에 Rollback을 적용할 예외를 설정합니다.

 

 

// AOP - Advice 등록
List<RollbackRuleAttribute> rollbackRules = new ArrayList<>();
rollbackRules.add(new RollbackRuleAttribute(Exception.class));

RuleBasedTransactionAttribute masterAttribute = new RuleBasedTransactionAttribute();
masterAttribute.setRollbackRules(rollbackRules);

// @Transactional
@Transactional(rollbackFor = Exception.class)

 

✔️ noRollbackFor

noRollbackFor, noRollbackForClassName

트랜잭션 롤백 예외 대상 지정

 

위와는 반대로, 기본적으로 롤백 대상인 런타임 예외를 제외시키고 싶을 때 사용하는 속성입니다.

롤백 대상의 예외를 커밋 대상으로 지정해줍니다. 예를 들어

 

@Transactional(noRollbackFor = MyCustomException.class)
public void myTransactionalMethod() {
    // 예외 발생 가능한 코드
}

 

위와 같이 선언하면 MyCustomException 클래스와 그 하위 클래스에 대해서는

롤백을 수행하지 않습니다.

 

 

 

 

 

 

 

 

 

 

 

출처 : https://gngsn.tistory.com/152