[Spring] @Transactional과 DB Lock에 DeepDive - (1) DB 트랜잭션, 사용방법, 격리수준, 전파 단계 훑어보기

 

🤔 0. DB 트랜잭션

더 이상 쪼갤 수 없는 최소 단위의 작업이라는 개념으로, commit()을 통해 모두 성공하든지 아니면 rollback()을 통해 모두 취소되어야 하는 작업 단위.

 

트랜잭션은 DB의 상태를 변경하는 하나의 작업 단위에 속합니다. 우리가 INSERT, UPDATE, DELETE 등의 SQL문을 실행하면, 자동으로 한 라인마다 트랜잭션이 적용되어 Commit을 실행하게 됩니다.

 

이러한 트랜잭션의 영역을 수동으로 설정해, 한 트랜잭션 안에 여러개의 명령문을 넣도록 변경할 수 있습니다.

START TRANSACTION;

....

COMMIT;

 

트랜잭션은 우리말로 '거래'라고 합니다. 예를 들어, A와 B가 거래를 하는 경우 A가 B에게 돈을 입금 했으나, B에게 사정이 생겨 물건을 보내지 못한 경우를 생각해 봅시다! 이 경우, A는 B에게 돈을 돌려받아야겠죠? 원래 거래를 시작하기 전 상황으로 되돌아가야 합니다.

 

따라서 개발에서의 DB 트랜잭션도 이와 유사한 의미로 생각하면 좋습니다. 다양한 작업 처리 중 오류가 발생했을 때, 트랜잭션 작업 단위 내의 모든 작업을 원상태로 돌릴 수 있다는 것이죠.

 

트랜잭션에서 사용되는 용어는 다음과 같습니다.

- Commit : 트랜잭션 내부의 모든 작업을 완료하고, 트랜잭션 내부의 작업 변경을 모두 승인하고 반영합니다.
- Rollback : 트랜잭션 내부의 모든 작업을 결과에 반영시키지 않고, 트랜잭션 시작 이전의 상태로 되돌립니다.

 

 

🤔 1. @Transactional의 사용방법

 

우리는 애플리케이션 프레임 워크인 스프링을 사용하고 있습니다. 스프링은 @Transactional 어노테이션을 활용한 선언적 트랜잭션 처리를 지원합니다.

 

이러한 선언적 트랜잭션이 어떤 방식으로 실행될 수 있는지에 대해서는 다음 포스팅에서 정리해보도록 하고, 오늘은 이러한 어노테이션 방식의 트랜잭션 적용은 어떻게 사용하는지에 대해 정리해 보려고 합니다.

 

1. 어디에 붙일 수 있는가?

@Transactional은 메서드, 클래스 위에 붙여 사용할 수 있습니다. 해당 어노테이션이 붙은 메서드는, 하나의 트랜잭션에 묶여 관리되게 됩니다. 이러한 일이 가능케 되는 이유(작동원리)에 대해서는 다음 포스팅에서 알아보려고 합니다.

 

@Transactional을 메서드와 클래스 레벨에 붙였을 때, 우선순위는 다음과 같습니다.

(우선순위 높음) 메서드 > 클래스 > interface method > interface (우선순위 낮음)

 

이러한 우선순위를 갖기 때문에 공통적인 트랜잭션 규칙은 클래스에, 특별한 규칙은 메서드에 붙이는 게 좋습니다.

또한 자바 어노테이션은 인터페이스로부터 상속되지 않기 때문에 클래스 기반 프록시 나 AspectJ 기반에서 트랜잭션 설정을 인식 할 수 없기 때문에 인터페이스 보다는 클래스에 적용하는 것이 좋습니다.

 

+ @Transactional은 일반적으로 Proxy 모드로 동작하기 때문에 Public 메소드에 설정해야 합니다. 다른 접근제어자에 대해서는 사용하지 못하거나, 에러가 발생하지는 않지만 동작하지 않는 경우가 있습니다.

 

 

2. @Transactional의 옵션

<사용 예시>

    @Transactional(isolation = Isolation.READ_COMMITTED, 
            propagation = Propagation.REQUIRED, 
            readOnly = true,  
            timeout = 30, 
            noRollbackFor = {SQLException.class}, 
            rollbackFor = {EntityNotFoundException.class})

 

• isolation :
  • 트랜잭션의 격리 수준 설정, 다른 트랜잭션에 어느정도 개입할 수 있는지에 대한 수준 설정이 가능.
  • 뒷 부분에서 추가로 다룰 예정
•  propagation :
  • 트랜잭션 동작 도중, 다른 트랜잭션을 호출 할 때, 어떤 방식으로 동작하는지, 전파되는지 설정이 가능.
  • 뒷 부분에서 추가로 다룰 예정
• noRollbackFor : 
  • 특정 예외 발생 시 rollback이 동작하지 않도록 설정
• rollbackFor : 
  • 특정 예외 발생 시 rollback이 동작하도록 설정
• timeout : 
  • 지정한 시간 내에 메소드 수행이 완료되지 않으면 rollback이 동작하도록 설정
• readOnly : 
  • 트랜잭션을 읽기 전용으로 설정

 

3. rollbackFor와 noRollbackFor 옵션

선언적 트랜잭션에서는, 기본적으로 RuntimeException에 대해 롤백을 하도록 설정이 되어있습니다. 

By default, a transaction will be rolling back on RuntimeException and Error but not on checked exceptions (business exceptions).

- docs 도중 발췌

그러나 Checked Exception에 대해서는 이러한 롤백 처리가 기본 설정으로 되어있지 않습니다.

 

그렇다고 해서 "CheckedException이라고 해서, 반드시 롤백을 하지 말아야 한다."라고 규정되어 있는 것은 없습니다. 

다른 블로그에서 "UncheckedException과 CheckedException에 대해 각각 롤백 처리를 해야 한다, 하지 말아야 한다"와 같이 단언해서 정리해 놓은 글을 많이 보았는데, 백기선님의 유튜브를 참고해 이러한 점은 잘못된 것이라는 것을 짚을 수 있었습니다.

 

따라서 롤백의 여부는 온전히 개발자의 몫입니다. CheckedException이라고 하더라도, 롤백이 필요한 상황이면 rollbackFor 옵션에 해당 Exception class를 추가해 롤백을 유도하면 됩니다.

 

역시 RuntimeException에서도, 롤백을 금지시킬 Exception이 있다면 noRollbackFor 옵션을 사용해 롤백을 하지 않도록 유도할 수 있습니다.

 

 

4. readOnly의 효과

readOnly의 뜻을 보면 알 수 있듯이, 해당 트랜잭션은 읽기 전용이라고 선언하는 것입니다.

readOnly 옵션을 사용했을 때의 이점은 다음과 같습니다.

- 수정, 삭제, 삽입 연산에 대해 허용하지 않는 트랜잭션이라는 의미로, 이러한 연산이 잘못 들어간 경우에 대해 방어가 가능함.
- readOnly를 사용함으로써 내부적인 속도 개선이 가능.

 

이러한 효과를 보았을 때, 우리는 트랜잭션을 적용시킬 때 읽기 전용이라고 명시할 수 있는 부분에는 반드시 명시하는 것이 좋다는 사실을 알 수 있습니다.

오늘은 사용 방법에 대한 정리이므로 이러한 readOnly의 내부 동작에 대해서는 다음 포스팅에서 정리하도록 하겠습니다.

 

 

🤔 2. 트랜잭션의 고립 단계

 

모든 DB 트랜잭션은 격리 수준(고립 단계)을 가지고 있습니다. 흔히 우리가 알고 있는 트랜잭션의 속성 ACID 중, I가 바로 isolation인 고립성을 의미합니다. 이러한 격리 수준에 대한 설정으로 고립성을 확보할 수 있는 것이죠.

 

서버 환경을 개발하면, 멀티쓰레드 환경에서 개발되기 때문에 동시에 여러 개의 트랜잭션이 실행될 수 있습니다. 이 때 고립성을 높게 설정한다면, 다른 트랜잭션에 의해 영향을 덜 받을 수 있으므로 고립성은 항상 고려되어야 할 사항입니다.

하지만, 고립성을 높게 설정하면 동시성이 떨어지게 됩니다. 즉 고립성을 높게 설정하면 동시성이 떨어지고, 동시성을 높이면 고립성이 떨어지게 됩니다. 즉 두 가지의 속성은 trade-off 관계에 있는 것이죠.

 

그럼 고립성을 낮췄을 때 발생할 수 있는 문제는 무엇이 있을까요?

이러한 문제는 DB 트랜잭션의 격리수준 설정과 함께 알아보도록 합시다!

 

 

 

@Transactional(isolation = Isolation.DEFAULT)

기본으로 선택된 트랜잭션의 고립단계입니다. 자신이 사용하고 있는 datasource에 의해 이러한 DEFAULT 값이 정해집니다. 

즉, 앞으로 나올

• READ_UNCOMMITTED
• READ_COMMITTED
• REPEATABLE_READ
• SERIALIZABLE

중에서 DataSource가 기본 값으로 선택한 격리 수준을 선택하게 됩니다.

 

 

@Transactional(isolation = Isolation.READ_UNCOMMITTED)

가장 낮은 단계의 고립 수준입니다. 

이름에서 알 수 있듯이, 트랜잭션 처리 중 혹은 커밋되기 이전의 데이터를 다른 트랜잭션이 읽는 것을 허용합니다.

어떤 사용자가 A라는 데이터를 B라는 데이터로 변경하는 동안 다른 사용자는 B라는 아직 완료되지 않은(Uncommitted 혹은 Dirty) 데이터 B를 읽을 수 있습니다.

 

출처 : byteslounge.com

 

READ_UNCOMMITTED에서 발생하는 Dirty Read는 다음과 같은 상황에서 문제가 됩니다.

A 트랜잭션에서 데이터를 삽입하고, B 트랜잭션에서 아직 커밋되지 않은 해당 데이터를 읽어들였습니다.

그러나 A 트랜잭션이 롤백이 된다면, A의 입력된 데이터는 적용되지 않고 돌아갑니다. 하지만 B 트랜잭션에서는 이미 해당 데이터를 읽어들였으므로, 존재하지 않는 데이터를 획득하게 되는 것입니다. 이러한 현상은 무결성을 깨뜨리므로, Dirty Read가 위험하다는 것을 알 수 있습니다.

 

 

@Transactional(isolation = Isolation.READ_COMMITTED)

이러한 Dirty Read 현상을 막기 위해 격리수준을 한 단계 높일 수 있습니다. 이 격리 수준은 바로 READ_COMMITTED입니다.

커밋된 데이터에 대해서만 다른 트랜잭션이 해당 데이터에 접근해서 읽어들일 수 있도록 하는 것이죠.

커밋이 안 된 데이터를 읽어들일 수 없으므로 Dirty Read와 같은 현상은 일어나지 않을 것입니다.

 

하지만, READ_COMMITTED에도 흠이 없는 것은 아닙니다.

출처 : byteslounge.com

 

 

위와 같은 Flow를 보게 되면, 트랜잭션 A에서는 x=1의 조건을 가진 데이터를 2회 시도하고 있습니다.

하지만 그 사이에 트랜잭션 B가 실행되어 x=1의 조건을 가진 데이터에 대해 수정 / 삭제를 시도하고 커밋을 한 상태입니다.

그렇다면, A 트랜잭션에서 첫 번째 Read와, 두 번째 Read는 서로 다른 값을 갖거나 (수정의 경우), 두 번째 Read에서 아예 없는 데이터를 찾으려고 할 수 있습니다.(삭제의 경우)

이러한 현상을 Non-repeatable reads라고 합니다. 한 트랜잭션 내에서 같은 조건에 대한 read가 동일하지 않은 값을 얻는다는 현상이죠.

 

 

@Transactional(isolation = Isolation.REPEATABLE_READ)

조금 더 격리 수준을 높여보겠습니다. REPEATABLE_READ로 격리 수준을 올리게 되면, 한 트랜잭션에서 같은 데이터에 대해 반복 조회를 하더라도 같은 값을 얻게 됩니다.

 

출처 : byteslounge.com

 

이렇게 격리 수준을 높였음에도, 위와 같은 상황에서 약간의 문제를 일으킬 수 있습니다.

방금과는 다르게 범위를 지정한 read를 실행하고, 트랜잭션 B에서는 해당 범위 내부에 속하는 데이터를 삽입하고 있습니다.

분명 트랜잭션 A에서 같은 조건으로 데이터 조회를 했지만, 첫 번째와 두 번째의 Read는 각각 결과 값이 다르게 나옵니다.

이러한 현상을 Phantom Read (유령읽기)라고 합니다.

 

 

@Transactional(isolation = Isolation.SERIALIZABLE)

가장 단순하면서 가장 엄격한 격리 수준입니다. 한 트랜잭션에서 읽고 쓰는 내용에 대해 다른 트랜잭션은 절대로 접근할 수 없습니다.

위에서 나온 모든 현상에 대해 제거가 가능하지만, 동시성이 지나치게 떨어져 사용을 지양합니다.

 

 

출처 : https://www.codeproject.com/Articles/1190420/Database-Transactions-with-Spring-Framework

 

 

간단하게 각 격리 수준이 어떤 것임을 확인했지만, MySQL에서 격리 수준의 설정에 따라 어떤 방식으로 동작하는지는 알지 못합니다.

이런 부분에 대해서 추가적으로 정리하도록 하겠습니다.

 

 

 

🤔 3. 트랜잭션의 전파 단계

 

트랜잭션 전파는, 트랜잭션의 경계에서 이미 진행 중인 트랜잭션이 있을 때, 또는 없을 때 어떻게 동작할 것인지를 결정하는 방식을 의미합니다.

예를 들어, A 메소드에 트랜잭션을 설정하고, B 메소드에 트랜잭션을 설정했습니다. A 메소드 내부에서 B 메소드를 호출한다고 가정해봅시다.

이 경우, A 메소드의 트랜잭션이 모두 끝나지 않은 상태에서, B 메소드의 트랜잭션이 실행됩니다. 그럼 이러한 B의 코드는 어떤 트랜잭션 안에서 실행되어야 할까요?

이러한 시나리오를 생각해 볼 수 있습니다.

- A에서 이미 시작한 트랜잭션에 편입
- 앞에서 이미 시작된 A 트랜잭션과 무관하게 독립적인 B 트랜잭션을 실행

이런 동작 방식을 결정하는 것이 바로 전파 단계의 조정입니다.

 

이러한 전파단계의 조정은 @Transactional의 propagation 옵션을 선택해서 조정할 수 있습니다.

 

@Transactional(propagtion = Propagation.REQUIRED)

가장 많이 사용되는 트랜잭션 전파 속성입니다. 진행중인 트랜잭션이 없다면 새로 시작하고, 이미 실행된 트랜잭션이 있으면 해당 트랜잭션으로 편입됩니다. 따라서 이러한 전파 속성을 가지고 있다면, 다양한 방식으로 서로 결합해 하나의 트랜잭션으로 구성하기 원활합니다. 

아래와 같이 기본적인 트랜잭션 전파 속성을 채택하고 있어서, 굳이 propagation 값을 설정하지 않더라도 자동 적용 됩니다.

 

 

@Transactional(propagtion = Propagation.REQUIRES_NEW)

항상 새로운, 독립적인 트랜잭션을 실행하게 하는 전파 전략입니다. 앞에서 시작된 트랜잭션이 있든 없든 상관없이 새로운 트랜잭션을 만들어서 독자적으로 동작되게 합니다. 독립적인 트랜잭션이 보장되어야 하는 코드에 적용시킬 수 있습니다.

또한 각각의 트랜잭션이 롤백되더라도, 전혀 영향을 끼치지 않습니다.

 

 

@Transactional(propagtion = Propagation.MANDATORY)

위에서 보았던, REQUIRED 전파 전략과 동일하게 부모 트랜잭션으로 편입이 된다는 점에서 굉장히 비슷하지만, 부모 트랜잭션이 없다면 예외를 발생시킨다는 차이점을 가지고 있습니다.

Mandatory는 '필수적인'이라는 뜻으로 부모 트랜잭션이 반드시 존재해야 하는 의미로 해당 단계 작명을 한 것 같습니다.

 

 

@Transactional(propagtion = Propagation.SUPPORTED)

위에서 보았던, REQUIRED 전파 전략과 동일하게 부모 트랜잭션으로 편입이 된다는 점에서 굉장히 비슷하지만, 부모 트랜잭션이 없다면 x트랜잭션을 생성하지 않는 차이점을 가지고 있습니다.

 

 

@Transactional(propagtion = Propagation.NESTED)

- 부모 트랜잭션이 없는 경우 : 새로운 트랜잭션을 생성해서 작동합니다.

- 부모 트랜잭션이 있는 경우 : 위의 예시들과는 다르게, '중첩 트랜잭션'을 생성합니다.

 

중첩 트랜잭션은 내부에서 오류가 발생해 롤백이 된다면, 중첩 트랜잭션만 롤백합니다.

중첩 트랜잭션이 롤백되어도, 부모 트랜잭션에는 영향을 끼치지 않습니다.

중첩 트랜잭션은 부모 트랜잭션이 모두 끝나고 커밋되는 시점에 같이 커밋됩니다. (모든 커밋은 부모 트랜잭션이 끝날 때 한 번.)

부모 트랜잭션이 롤백하면, 중첩 트랜잭션도 롤백됩니다.

 

 

@Transactional(propagtion = Propagation.NEVER)

트랜잭션을 생성하지 않고, 부모 트랜잭션이 존재한다면 예외를 발생시킵니다.

 

 

 

 

🏝 출처

[도서] 토비의 스프링 3.1
[링크] https://www.youtube.com/watch?v=_WkMhytqoCc&t=152s (백기선님 유튜브)
[링크] https://tecoble.techcourse.co.kr/post/2021-05-25-transactional/ (tecoble)
[링크] https://data-make.tistory.com/738
[링크] https://brush-up.github.io/java/java-springboot-transactional/
[링크] https://www.codeproject.com/Articles/1190420/Database-Transactions-with-Spring-Framework
[링크] https://incheol-jung.gitbook.io/docs/q-and-a/db/isolation-level
[링크] https://steady-coding.tistory.com/562