트랜잭션 격리 수준

데이터베이스 트랜잭션 격리 수준

데이터베이스 트랜잭션의 격리 수준은 격리성(각각의 트랜잭션은 서로 간섭없이 독립적으로 수행되어야한다는 규칙)의 견고함 정도를 말합니다.

트랜잭션 격리 수준

트랜잭션의 격리 수준은 총 네 단계로 나뉩니다.

• READ UNCOMMITED
• READ COMMITED
• REPEATABLE READ
• SERIALIZABLE

READ-UNCOMMITED가 가장 성능이 낮은 대신 가볍고, SERIALIZABLE이 가장 성능이 높으며 무겁습니다.

때문에 프로덕트 케이스에 맞는 트랜잭션 격리 수준을 선택하면 되겠습니다.

 

성능이 좋고 나쁘고는 어떻게 판단하나요?

성능을 판별하는 기준은 격리성을 얼마나 잘 유지하느냐입니다.

위에서 설명한 네가지 격리 수준에서는 아래와 같은 이슈가 발생합니다.

• DIRTY READ
• NON-REPEATABLE READ
• PHANTOM READ

격리 수준	DIRTY READ	NON-REPEATABLE READ	PHANTOM READ
READ UNCOMMITED	X	X	X
READ COMMITED	-	X	X
REPEATABLE READ	-	-	X
SERIALIZABLE	-	-	-

READ UNCOMMITED

커밋 전에 트랜잭션의 데이터 변경 내용을 다른 트랜잭션이 읽는 것을 허용.
여기서 발생할 수 있는 에러는 DIRTY READ, NON-REPEATABLE READ, PHANTOM READ입니다.

커밋 전에 트랜잭션이 상호 READ가 가능하다면 아래와 같은 문제가 발생합니다.

 

DIRTY READ

커밋되기 전 값이 끝까지 적용되지 않고 중간에 롤백되어 버린다면 업데이트 된 데이터를 다른 트랜잭션에서 가져올 수 있습니다.

 

READ COMMITED

커밋 완료된 트랜잭션의 변경사항만 다른 트랜잭션에서 조회 가능
여기서 발생할 수 있는 에러는 NON-REPEATABLE READ, PHANTOM READ입니다.

NON-REPEATABLE READ만 설명하겠습니다.

 

NON-REPEATABLE READ

같은 데이터를 2번 조회했는데 다른 결과값이 RETURN 되는 이슈입니다.

 

REPEATABLE READ

트랜잭션 범위 내에서 조회한 내용이 항상 동일함을 보장함.
아래와 같이 UPDATE 되지 않은 값을 반환함으로써 이슈를 해결했습니다.

이번에는 PHANTOM READ 이슈가 발생합니다.

 

PHANTOM READ

팬텀 리드는 데이터가 삽입/삭제되었을 때 조회 조건문에 RETURN 되는 값들이 추가/삭제 될 수 있다는 이슈입니다.

 

SERIALIZABLE

한 트랜잭션에서 사용하는 데이터를 다른 트랜잭션에서 접근 불가.

동시 작업을 아예 막아버림으로써 동시성에서 발생할 수 있는 이슈가 없습니다.

다만, 가장 성능이 떨어집니다.

 

 

트랜잭션 전파 타입

트랜잭션 전파 타입은 쉽게 트랜잭션이 시작하거나 참여하는 방법에 관한 설정입니다.

현재 트랜잭션 상태에 따라 어떻게 처리하라 정할 수 있습니다.

 

TypeORM도 cls-hoooked이라는 라이브러리에서 Spring과 같이 총 7개를 지원하고 있어서 표를 첨부합니다.

 

트랜잭션 전파 타입	진행중인 트랜잭션이 있을때	진행중인 트랜잭션이 없을 때
MANDATORY	현재 트랜잭션 사용	예외 발생
NESTED	중첩 트랜잭션 생성	새로운 트랜잭션 생성
NEVER	예외 발생	트랜잭션 없이 진행
NOT_SUPPORTED	해당 트랜잭션 보류	트랜잭션 없이 진행
REQUIRED	해당 트랜잭션 사용	새로운 트랜잭션 생성
REQUIRES_NEW	해당 트랜잭션 보류, 새로운 트랜잭션 생성	새로운 트랜잭션 생성
SUPPORTS	해당 트랜잭션 사용	트랜잭션 없이 진행

레퍼런스

• https://fauna.com/blog/database-transaction
• https://youtu.be/e9PC0sroCzc
• https://github.com/odavid/typeorm-transactional-cls-hooked