DBMS에서 데이터에 대한 동시 접근이 발생한 경우, 일관성과 무결성을 지키기 위해 해당 데이터에 잠금을 걸 수 있다. 이 때 select 가능 여부에 따라 크게 공유 락과 배타 락으로 나누게 된다.
공유락 (shared lock)
공유 락이 걸린 데이터에 대해서는 읽기 연산(SELECT)만 실행 할수 있고, 쓰기 연산(WRITE)은 실행하지 못한다. 공유 락을 사용하면, 조회한 데이터가 트랜잭션 내내 변경되지 않음을 보장한다.
즉, 공유 락이 걸린 데이터는 다른 트랜잭션도 똑같이 공유 락을 획득할 수 있으나, 배타 락은 획득할 수 없다. 공유 락이 걸려도 읽기 작업은 가능하다는 뜻이다.
배타락 (exclusive lock)
배타락이 걸린 데이터에 대해서는 읽기 연산(SELECT)과 쓰기 연산(WRITE)을 모두 실행할 수 없다. 다른 트랜잭션은 배타 락이 걸린 데이터에 대해 읽기 작업도, 쓰기 작업도 수행할 수 없다.
즉, 배타 락이 걸려있다면 다른 트랜잭션은 공유 락, 배타 락 둘 다 획득 할 수 없다. 배타 락을 획득한 트랜잭션은 해당 데이터에 대한 독점권을 갖는 것이다.
예시
공유락
Lock을 테스트하기 위해서는 서로 다른 connection이 필요하기 때문에 두개를 띄워서 테스트 해야한다.
- Shared Lock은 select 절 뒤에 for share를 명시하여 lock을 생성할 수 있다.
- data의 lock 여부는 아래 쿼리를 통해 확인 할 수 있고 lock_mode의 S 표시가 Shared Lock 이라는 의미이다.
배타락
- Exclusive Lock은 select 절 뒤에 for update 를 명시하여 lock을 생성할 수 있다.
=> Exclusive Lock은 읽기 쓰기 모두 잠금하기 때문에 이후에 실행한 오른쪽 쿼리는 대기상태에 걸린 것을 볼 수 있다.
- data의 lock 여부는 아래 쿼리를 통해 확인 할 수 있고 lock_mode의 S 표시가 Shared Lock 이라는 의미이다.
Exclusive Lock이 걸린 row를 Select 하기
유의할부분은 Exclusive Lock을 걸었다고 해서 Shared Lock이 아닌 읽기(Select)는 일반적으로 잠금하지 않는다. MVCC(Mutiple-Version Concurrency Control)로 인하여 스냅샷을 읽기 때문이다. 만약 select에도 공유락을 획득하게끔 하고 싶다면 격리수준 설정을 바꿔주면 된다.
- READ UNCOMMITTED: 배타락 무시하고 더티 리드 가능
- READ COMMITTED / REPEATABLE READ: 일반 SELECT는 실행, Locking Read는 대기
- REPEATABLE: 일반 SELECT도 공유락을 획득하려 하므로 대기
락이 필요한 이유?
동시성제어 방법으로 Isolation Level이 있다. 여러 트랜잭션이 동시에 실행될 때, 서로 얼마나 격리시킬지를 정하는 설정이다. 낮은 격리 수준은 빠르지만 데이터 불일치 가능성이 있고 높은 격리 수준은 느리지만 데이터 정확성 보장한다. 이로써 어느정도 동시성을 제어할 수 있다.
다만 아쉬운점은 이 Isolation level은 connection 단위로만 적용가능하다. 트랜잭션 내에서 Select한 데이터에 대해 다른 트랜잭션에 대한 동시성을 제어하고 싶은 경우에 필요한 것이 데이터베이스의 Lock이다.
DBMS에서 데이터에 대한 동시 접근이 발생한 경우, 일관성과 무결성을 지키기 위해 해당 데이터에 잠금을 걸 수 있다. 이 때 select 가능 여부에 따라 크게 공유 락과 배타 락으로 나누게 된다. 공유락은 공유락이 걸린 데이터에 대해서 읽기는 가능하고 쓰기 작업을 불가한 락이다. 공유락을 사용하면 조회한 데이터 트랜잭션 내에서 변경되지 않음을 보장할 수 있다. 공유 락이 걸린 데이터는 다른 트랜잭션도 똑같이 공유 락을 획득할 수 있으나, 배타 락은 획득할 수 없다. 배타락이 걸린 데이터에 대해서 읽기/쓰기 작업 모두 불가한 락이다. 배타 락이 걸려있다면 다른 트랜잭션은 공유 락, 배타 락 둘 다 획득 할 수 없고 대기 상태에 들어간다. 배타 락을 획득한 트랜잭션은 해당 데이터에 대한 독점권을 갖는 것이다.
