본문 바로가기
CS/데이터베이스

공유 락과 배타 락

by 순원이 2024. 12. 10.

공유 락(Shared Lock)은 무엇인가요? 😀


공유 락은 읽기 락(Read Lock)이라고 부르며, 공유 락이 걸린 데이터는 읽기(SELECT)연산만 **가능**하며, 쓰기(UPDATE, DELETE)는 **불가능**합니다. 공유 락이 걸린 데이터에 대해서 **다른 트랜잭션에서도 공유 락을 획득**할 수 있지만, 배타 락은 획득할 수 없습니다. 즉, 공유 락을 사용하면 **트랜잭션 내에서 조회한 데이터가 변경되지 않는**다는 것을 보장합니다.

SELECT * FROM table_name WHERE id = 1 FOR SHARE;

배타 락(Exclusive Lock)은 무엇인가요? 🤔


배타 락은 쓰기 락(Write Lock)이라고 부르며, 배타 락을 획득한 트랜잭션은 읽기, 쓰기 연산 모두 **가능**합니다. 하지만 다른 트랜잭션에서는 읽기, 쓰기 모두 **불가능**합니다. 즉, 배타 락을 획득한 트랜잭션은 데이터에 대한 독점권을 가집니다.

SELECT * FROM table_name WHERE id = 1 FOR UPDATE;

정리하자면, 공유 락이 걸린 데이터는 다른 트랜잭션에서 공유 락을 획득 할 수 있고, 배타 락이 걸린 데이터는 다른 트랜잭션에서 어떤 종류의 락도 획득할 수 없어서 대기하게 됩니다.

배타 락 사용시 어떤 상황에 데드 락이 발생하나요?


데드 락(Dead Lock)이란 교착 상태로, 두개 이상의 트랜잭션이 서로 필요로 하는 데이터의 락을 점유하고 있어서 무한히 대기하는 상황을 말합니다. 트랜잭션은 락을 획득하지 못하는 경우, 다른 트랜잭션이 점유하고 있는 락이 해제될 때 까지 대기합니다.

트랜잭션 T1과 T2가 있다고 가정해보겠습니다.

  1. T1이 데이터 A에 대해 공유락을 획득
  2. T2가 데이터 B에 대해 공유락을 획득
  3. T1이 데이터 B에 대해 배타락(exclusive lock)을 요청하지만, T2가 이미 공유락을 가지고 있어서 대기
  4. T2가 데이터 A에 대해 배타락을 요청하지만, T1이 이미 공유락을 가지고 있어서 대기

이런 상황에서 두 트랜잭션은 서로가 가진 자원을 기다리며 데드락에 빠지게 됩니다.

데드 락을 해결하는 방법은 뭔가요?


  1. 트랜잭션에서 락 획득 순서를 일관되게 합니다. 모든 트랜잭션에서 1번 데이터, 2번 데이터 순으로 락을 획득할 시 데드 락이 발생하지 않습니다.
  2. 락 타임 아웃을 설정합니다.

잠금 없는 읽기


InnoDB 스토리지 엔진을 사용하는 테이블에서는 한 가지 주의할 점이 있다. FOR UPDATE 혹은 FOR SHARE 절을 가지지 않는 SELECT 쿼리는 잠금 없는 읽기가 지원된다. 따라서 특정 데이터가 FOR UPDATE 로 락이 걸린 상태라도 FOR UPDATE , FOR SHARE 가 없는 단순 SELECT 쿼리는 아무런 대기 없이 해당 데이터를 조회할 수 있습니다.

정리


  • 가장 상위 개념: 낙관적 락 vs 비관적 락
    • 낙관적 락: 충돌이 적을 것이라 가정하고, 데이터 수정 시점에 충돌을 확인
      • 버전 관리나 타임스탬프를 사용
      • 충돌이 적은 상황에서 성능이 좋음
      • JPA의 @Version 등으로 구현
    • 비관적 락: 충돌이 많을 것이라 가정하고, 데이터 읽을 때부터 락을 검
      • 실제 DB 락을 사용
      • 충돌이 많은 상황에서 유리
      • 공유락과 배타락이 비관적 락의 구현 방식임
  • **비관적 락**의 종류: 공유락 vs 배타락
    • 공유락(Shared Lock, S락)
      • 읽기 작업을 위한 락
      • 다른 트랜잭션의 읽기는 허용 (공유락 획득 가능)
      • 다른 트랜잭션의 쓰기는 불가 (배타락 획득 불가)
    • 배타락(Exclusive Lock, X락)
      • 쓰기 작업을 위한 락
      • 다른 트랜잭션의 읽기도 불가 (공유락 획득 불가)
      • 다른 트랜잭션의 쓰기도 불가 (배타락 획득 불가)

참고


'CS > 데이터베이스' 카테고리의 다른 글

[Real MySQL 9장] 옵티마이저와 힌트  (0) 2025.01.09
[Real MYSQL 10장] 실행 계획  (0) 2025.01.03
MySQL 아키텍쳐  (1) 2024.11.26
MySQL 인덱스  (0) 2024.11.26