락(Lock) | Atelier

type

status

date

slug

summary

Lock

각 클라이언트로부터 동일한 데이터베이스의 데이터에 동시에 접근하지 못하도록 트랜잭션이 완료되기 전까지 조회를 제한하는 행위 ACID 원칙 중 고립성(Isolation)을 준수하기 위함임

A와 B가 게시글에 동시에 접근하면 기대값은 2여야 하나 조회수가 1이 오르게 된다.

A 와 B 모두 이전 state 값에서 +1을 수행하기 때문이다.

공유 락은 데이터를 읽을 때 사용되는 락 방식입니다. 여러 트랜잭션이 동시에 데이터를 읽을 수 있지만, 데이터 수정은 불가능합니다. 이는 데이터의 일관성을 유지하면서 동시에 여러 사용자가 데이터를 읽을 수 있게 해줍니다.

베타 락은 데이터를 수정할 때 사용되는 락 방식입니다. 한 트랜잭션이 베타 락을 획득하면 다른 트랜잭션은 해당 데이터를 읽거나 수정할 수 없습니다. 이는 데이터의 일관성을 보장하지만, 동시성을 제한할 수 있습니다.

업데이트 락은 공유 락과 베타 락의 중간 형태입니다. 이 락은 데이터를 읽을 때는 공유 락처럼 작동하지만, 데이터를 수정하려고 할 때는 베타 락으로 변환됩니다. 이는 데드락을 방지하면서도 동시성을 유지하는 데 도움이 됩니다.

내재 락은 데이터베이스 시스템에서 계층적 잠금을 구현하는 데 사용되는 락 유형입니다. 이는 특정 리소스에 대한 잠금 의도를 나타내며, 실제 잠금을 획득하기 전에 사용됩니다. 내재 락은 데이터베이스의 성능을 최적화하고 데드락을 방지하는 데 도움이 됩니다.

방법	내용
마지막 커밋만 인정하기	사용자 A의 내용은 무시하고 마지막에 커밋한 사용자 B의 내용만 인정하기
최초 커밋만 인정하기	사용자 A가 이미 수정을 완료했으므로 사용자 B가 수정을 완료할 때 오류 발생시키기
충돌하는 갱신 내용 병합하기	사용자 A와 사용자B의 수정사항을 병합하기

트랜잭션 대부분은 충돌이 발생하지 않는다고 낙관적으로 가정하는 방법 때문에 트랜잭션 commit 전까지 충돌 여부를 알 수 없음

트랜잭션의 충돌이 발생한다고 가정하고 우선적으로 락을 거는 방법 DB에서 기본 제공하는 select for update 를 사용

하지만 따로 분리실행되었다고 해도 두 번의 갱신 분실 문제 가 발생할 수 있다

A와 B가 동시에 데이터를 수정한다고 할 때 근소한 차이로 A, B 순서로 수행된다면 A의 데이터는 어떡할 것인가?

모드	타입	설명
낙관적	OPTIMISTIC	낙관적 락을 사용
낙관적	OPTIMISTIC_FORCE_INCREMENT	낙관적 락 + 버전 정보를 강제로 증가
비관적	PESSIMISTIC_READ	비관적(read) 락 사용
비관적	PESSIMISTIC_WRITE	비관적(write) 락 사용
비관적	PESSIMISTIC_FORCE_INCREMENT	비관적 락 + 버전 정보 강제 증가
기타	NONE	락 X
기타	READ	OPTIMISTIC(JPA1.0 호환)
기타	WRITE	OPTIMISTIC_FORCE_INCREMENT(JPA1.0 호환)