[Spring] @Transactional 옵션 알아보기 + 트랜잭션 전파

@Transactional에 대해 궁금하다면 아래 포스팅을 읽어보는 것을 추천드립니다.

트랜잭션이란? 특징과 사용법에 대해 쉽게 알아보자

---

트랜잭션 전파

트랜잭션을 각각 사용하는 것이 아니라, 트랜잭션이 이미 진행중인데, 여기에 추가로 트랜잭션을 진행 시킬 수 있습니다.

이런 경우 어떻게 동작할지 결정하는 것을 트랜잭션 전파(propagation)라 합니다.

 

트랜잭션이 하나일 경우

먼저 트랜잭션이 하나 있을 경우를 봅시다.

트랜잭션 처리는 한번에 이루어져야하는 작업의 묶음으로 전체가 정상적으로 완료되면 커밋, 전체 중 일부라도 오류가 발생하면 롤백됩니다.

위 예시 그림을 보면 Servcie가 로직2를 수행하여 LogRepository에 접근했는데 예외가 발생했습니다.

그러면 어떻게 될까요 ? 전체가 정상적으로 완료되지 않았기 때문에 롤백이 일어납니다.

그런데 LogRepository에서 발생한 예외를 try ~ catch로 잡으면 두 로직이 정상적으로 수행되었기 때문에 커밋됩니다.

 

각각에 트랜잭션을 적용했을 경우

그럼 Service에 트랜잭션을 적용하지 않고 각 Repository에 트랜잭션을 적용했을 경우 한 쪽에서 예외가 발생한다면 어떻게 될까요 ?

각각 다른 트랜잭션을 사용중이므로 Repository는 커밋, LogRepository는 롤백 됩니다.

 

트랜잭션이 이미 진행중인데, 여기에 추가로 트랜잭션을 진행시키는 경우

자 이제 트랜잭션이 이미 진행중인데, 여기에 추가로 트랜잭션을 진행시키는 경우를 봅시다.

이 경우를 그림으로 보면 다음과 같습니다.

스프링은 물리 트랜잭션과 논리 트랜잭션이라는 개념을 나누는데, 논리 트랜잭션들은 하나의 물리 트랜잭션으로 묶입니다.

Service 안에서 Repository들을 호출하므로 Service가 외부 논리 트랜잭션, 두 Repository가 내부 논리 트랜잭션으로 구분하였습니다.

물리 트랜잭션	실제 데이터 베이스에 적용되는 트랜잭션 실제 커넥션을 통해 트랜잭션이 시작하고, 실제 커넥션을 통해 커밋, 롤백하는 단위
논리 트랜잭션	트랜잭션 매니저를 통해 트랜잭션을 사용하는 단위

 

전파 옵션 기본값인 REQUIRED 옵션을 예를 들어 설명해 보면 다음과 같습니다.

 

- 모든 로직이 정상 수행되었을 경우

- 논리 트랜잭션에서 예외가 발생했을 경우

 

REQUIRES_NEW 옵션을 사용해 물리 트랜잭션을 별도로 분리

예외가 발생하는 LogRepository를 REQUIRES_NEW 옵션을 사용해 물리 트랜잭션을 별도로 분리하여

정상적으로 수행된 Service와 Repository는 커밋, 예외가 발생한 LogRepository만 롤백하도록 할 수 있습니다.

예외가 발생하는 트랜잭션에 REQUIRES_NEW 옵션을 적용하여 별도의 물리 트랜잭션을 생성하여 2개의 물리 트랜잭션 A, B으로 분리되었습니다.

예외가 발생하는 LogReposiotry 논리 트랜잭션은 신규 트랜잭션으로 물리 트랜잭션B 에게 롤백을 호출하고, 물리 트랜잭션 B는 롤백됩니다.

물리 트랜잭션 A의 논리 트랜잭션은 둘다 정상 수행되었으므로 신규 트랜잭션인 Service가 물리 트랜잭션A에 커밋을 요청하여 물리 트랜잭션 A는 커밋을 수행합니다.

 

---

@Transactional 옵션

propagation (트랜잭션 전파 옵션)

스프링은 다양한 트랜잭션 전파 옵션을 제공하며,

보통은 기본값인 REQUIRED를 사용하고 가끔 REQUIRES_NEW을 사용해 나머지는 거의 사용하지 않습니다.

 

REQUIRED

가장 많이 사용하는 기본 설정.

트랜잭션이 필수로, 기존 트랜잭션이 없으면 생성하고, 있으면 참여

이 때 기존 트랜잭션에 참여했기 때문에 하나의 커넥션을 사용하게 됩니다.

• 기존 트랜잭션 없음: 새로운 트랜잭션을 생성
• 기존 트랜잭션 있음: 기존 트랜잭션에 참여

 

REQUIRES_NEW

항상 새로운 트랜잭션을 생성

이 때 기존 트랜잭션이 있음에도 생성했기 때문에 커넥션을 추가로 사용하게 됩니다.

• 기존 트랜잭션 없음: 새로운 트랜잭션을 생성
• 기존 트랜잭션 있음: 새로운 트랜잭션을 생성

 

SUPPORT

트랜잭션을 지원한다는 뜻.

기존 트랜잭션이 없으면, 없는대로 진행하고, 있으면 참여한다.

• 기존 트랜잭션 없음: 트랜잭션 없이 진행
• 기존 트랜잭션 있음: 기존 트랜잭션에 참여

 

NOT_SUPPORT

트랜잭션을 지원하지 않는다는 의미.

• 기존 트랜잭션 없음: 트랜잭션 없이 진행
• 기존 트랜잭션 있음: 트랜잭션 없이 진행 (기존 트랜잭션은 보류한다)

 

MANDATORY 

의무사항, 트랜잭션이 반드시 있어야 한다.

기존 트랜잭션이 없으면 예외가 발생.

• 기존 트랜잭션 없음: IllegalTransactionStateException 예외 발생
• 기존 트랜잭션 있음: 기존 트랜잭션에 참여

 

NEVER

트랜잭션을 사용하지 않는다는 의미.

기존 트랜잭션이 있으면 예외가 발생

• 기존 트랜잭션 없음: 트랜잭션 없이 진행
• 기존 트랜잭션 있음: IllegalTransactionStateException 예외 발생

 

NESTED

중첩 트랜잭션은 외부 트랜잭션의 영향을 받지만, 중첩 트랜잭션은 외부에 영향을 주지 않습니다.

중첩 트랜잭션이 롤백 되어도 외부 트랜잭션은 커밋할 수 있고, 외부 트랜잭션이 롤백 되면 중첩 트랜잭션도 함께 롤백됩니다.

• 기존 트랜잭션 없음: 새로운 트랜잭션을 생성
• 기존 트랜잭션 있음: 중첩 트랜잭션을 만든다.

참고

JDBC savepoint 기능을 사용한다. DB 드라이버에서 해당 기능을 지원하는지 확인이 필요하다. 중첩 트랜잭션은 JPA에서는 사용할 수 없다. 트랜잭션 전파와 옵션 isolation , timeout , readOnly 는 트랜잭션이 처음 시작될 때만 적용된다. 트랜잭션에 참여하는 경우에는 적용되지 않는다. 예를 들어서 REQUIRED 를 통한 트랜잭션 시작, REQUIRES_NEW 를 통한 트랜잭션 시작 시점에만 적용된다.

---

readonly

트랜잭션은 기본적으로 읽기 쓰기가 모두 가능한 트랜잭션이 생성되는데,  readOnly=true 옵션을 사용하면 읽기 전용 트랜잭션이 생성됩니다.

이 경우 등록, 수정, 삭제가 안되고 읽기 기능만 작동합니다.

readOnly 옵션을 사용하면 예상치 못한 엔티티의 변경, 삭제를 예방할 수 있고 성능 최적화가 발생할 수 있습니다.

@Transactional(readOnly = true) // 기본값은 false

 

readOnly 옵션으로 성능 최적화가 발생하는 이유

- 프레임워크

1. JdbcTemplate은 읽기 전용 트랜잭션 안에서 변경 기능을 실행하면 예외를 던진다.
2. JPA(하이버네이트)는 읽기 전용 트랜잭션의 경우 커밋 시점에 플러시를 호출하지 않는다. (읽기 전용이니 변경에 사용되는 플러시를 호출할 필요가 없다.)
3. 추가로 변경이 필요 없으니 변경 감지를 위한 스냅샷 객체도 생성하지 않는다.
4. 이렇게 JPA에서는 다양한 최적화가 발생한다.

- JDBC 드라이버

1. 읽기 전용 트랜잭션에서 변경 쿼리가 발생하면 예외를 던진다.
2. 읽기, 쓰기(마스터, 슬레이브) 데이터베이스를 구분해서 요청한다.
3. 읽기 전용 트랜잭션의 경우 읽기 (슬레이브) 데이터베이스의 커넥션을 획득해서 사용한다.

- 데이터베이스

데이터베이스에 따라 읽기 전용 트랜잭션의 경우 읽기만 하면 되므로, 내부에서 성능 최적화가 발생한다.

---

isolation

트랜잭션 격리 수준을 지정할 수 있습니다.

기본 값은 데이터베이스에서 설정한 트랜잭션 격리 수준을 사용하는 DEFAULT 값으로 대부분 데이터베이스에서 설정한 기준을 따릅니다.

 

애플리케이션 개발자가 트랜잭션 격리 수준을 직접 지정하는 경우는 드뭅니다.

( 이 분에 대한 내용은 위 트랜잭션 포스팅에 포함되어 있습니다. )

• DEFAULT : 데이터베이스에서 설정한 격리 수준을 따른다.
• READ_UNCOMMITTED : 커밋되지 않은 읽기
• READ_COMMITTED : 커밋된 읽기 ( 일반적으로 많이 사용 )
• REPEATABLE_READ : 반복 가능한 읽기
• SERIALIZABLE : 직렬화 가능

---

timeout

트랜잭션 수행 시간에 대한 타임아웃을 초 단위로 지정합니다.

지정한 시간 내에 해당 메소드 수행이 완료되지 않을 경우 rollback을 수행합니다.

기본 값은 -1 (no timeout)

@Transactional(timeout=10)

---

rollbackFor

예외 발생시 스프링 트랜잭션은 체크 예외, 언체크 예외를 보고 다음과 같이 수행합니다.

• 체크 예외인 Exception 과 그 하위 예외들은 롤백하지 않고 커밋
• 언체크 예외인 RuntimeException , Error 와 그 하위 예외가 발생하면 롤백.

체크 예외의 경우에도 트랜잭션을 커밋하지 않고 롤백하고 싶을 수 있는데,

이 옵션을 사용하면 기본 정책에 추가로 어떤 예외가 발생할 때 롤백할 지 지정할 수 있습니다.

@Transactional(rollbackFor = Exception.class)

이렇게 지정하면 체크 예외인 Exception 이 발생해도 롤백하게 됩니다. (하위 예외들도 대상에 포함.)

---

noRollbackFor

앞서 설명한 rollbackFor 와 반대로

어떤 예외가 발생했을 때 롤백하면 안되는지 지정할 수 있습니다. (하위 예외들도 대상에 포함.)

@Transactional(noRollbackFor=RuntimeException.class)