부정합 이슈
Dirty Read: 다른 트랜잭션에서 처리한 작업이 완료되지 않았음에도 불구하고 다른 트랜잭션에서 볼 수 있는 현상
Non-Repeatable Read: 하나의 트랜잭션내에서 동일한 SELECT 쿼리 실행시 항상 같은 결과를 보장해야하는 Reapeatable Read 정합성에 어긋난 것
Phantom Read: 읽을 때 쓰기 잠금을 거는 경우 다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다가 안보였다가 하는 현상
트랜잭션 격리 수준
Read Uncommitted
읽기 트랜잭션이 시작했을 때 다른 트랜잭션이 Update 가능
읽기 트랜잭션이 Update 중(un-commit)인 데이터를 조회할 수 있음
⇒ 다른 트랜잭션이 중간에 롤백을 해도 읽기 트랜잭션은 롤백 전 데이터를 조회할 수 있음
⇒ 다른 트랜잭션의 Update(커밋)과 무관하게 일관된 데이터를 얻을 수 없는 확률 높음 == Dirty Read
Read Committed
읽기 트랜잭션이 시작했을 때 다른 트랜잭션이 Update 가능
읽기 트랜잭션은 다른 트랜잭션에서 Update 완료(commit)된 데이터만 조회할 수 있음
⇒ Dirty Read 발생할 수 없음,
⇒ ex) 읽기 트랜잭션을 열어두고 조회한 후, 그 사이에 다른 트랜잭션이 Update 트랜잭션을 수행하고 commit 하면, 다시 읽기 트랜잭션이 조회하면 처음 조회한 것과 결과가 달라질 수 있음 (Repeatable Read 어김)
일반적인 웹 어플리케이션에선 크게 문제 안될수도?, But 은행같이 금전적인 처리와 연결되면 문제될 수 있음.
Repeatable Read
읽기 트랜잭션이 시작했을 때 다른 트랜잭션 Update 가능
읽기 트랜잭션은 자기자신이 시작한 순간 이전의 데이터 상태만 조회할 수 있음
⇒ Non-Repeatable Read 발생할 수 없음
⇒ 다른 트랜잭션의 Update와 상관없이 일관된 데이터 얻을 수 있음
But, Insert, Delete에 따라 결과 달라질 수 있음
⇒ Phantom Read 이슈 발생할 수 있음
발생하는 이유는 undo 레코드에 잠금을 걸 수 없기에
undo 영역의 변경 전 데이터를 가져오는 거싱 아니라
현재 레코드의 값을 가져오게 됨
Serializable
읽기 작업도 공유 잠금을 획득해야하고, 동시에 다른 트랜잭션은 변경 불가, 즉 한 트랙잭션에서 읽고 쓰는 레코드는 다른 트랜잭션에서 절대 접근 불가
⇒ 동시 처리 성능 매우 떨어짐, 모든 부정합 문제 발생X
'TIL > TIL' 카테고리의 다른 글
Inner Class로 DTO 관리 (0) | 2023.05.10 |
---|---|
Lombok @Builder vs @Accessor vs Setter (0) | 2023.04.21 |
Node.js와 Express 그리고 Nest.js (2) | 2022.10.03 |
[TIL] MicroServices Architecture(MSA) vs Monolithic Architecture (0) | 2022.09.26 |
[CS] 자료구조/알고리즘 관련(작성중...) (2) | 2022.09.26 |
댓글