[매일메일] 공유 락 vs 배타 락

 

공유 락(Shared Lock,  Read Lock)과 배타 락(Exclusive Lock, Write Lock)은 비관적 락의 데이터 일관성과 무결성을 위해 사용한다.

공유 락 vs 배타 락

 

 공유 락은 Read Lock으로도 불리며, 공유 락이 걸린 데이터는 읽기 연산(SELECT)만 가능하며 그 외에 쓰기 연산(UPDATE, DELETE)은 불가능하다. 이때 다른 트랜잭션에서도 공유락이 걸린 데이터에 대해 또 다른 공유 락은 획득할 수 있지만 배타 락은 획득할 수 없다. 즉 공유락을 사용함으로써 트랜잭션 내에서 조회한 데이터가 변경되지 않았음을 보장받을 수 있다.

 

 배타 락은 Write Lock으로도 불린다. 즉 배타 락을 획득한 트랜잭션은 읽기 그리고 쓰기 연산이 모두 가능하다. 하지만 다른 트랜잭션에서는 읽기와 쓰기 모두 불가능해진다.

 

이러한 공유 락과 배타 락은 비관적 락에서 사용된다는데, 그럼 이제 비관적 락과 낙관적 락에 대해 알아보자.

비관적 락 vs 낙관적 락

 

 비관적 락(Pessimistic Lock)은 트랜잭션 시작 시 공유 락 또는 배타 락을 걸고 시작하는 방식을 뜻한다. 즉 트랜잭션을 이용하여 충돌을 예방한다. 만약 비관적 락을 사용할 때 충돌이 발생하면? 트랜잭션을 롤백하면 된다.

 

 반면에 낙관적 락(Optimistic Lock)은 자원에 락을 걸지 않는 대신 동시성 문제가 발생하면 그때마다 처리하는 방식이다. 낙관적 락은 version 혹은 hashcode, timestamp와 같은 별도의 칼럼을 추가하여 충돌의 발생을 막는다. 즉 트랜잭션을 이용하지 않고 애플리케이션 단에서 충돌을 잡아줘야 한다. 그럼 낙관적 락 사용 시 충돌이 발생하면? 개발자가 수동으로 롤백처리를 해주어야 한다.

 

 그럼 충돌이 많이 발생하면서 데이터의 무결성이 중요한 환경에서는 롤백이 쉬운 비관적 락이 유리하고, 충돌이 많이 발생하지 않을 것으로 예상되면서 조회 작업이 많아 동시 접근 성능이 중요한 환경에서는 트랜잭션을 필요로 하지 않아 성능적으로 유리한 낙관적 락이 더 유리하다.

배타 락 사용 시 데드락이 발생하는 경우?

 

2024 Fall 경북대학교 데이터베이스 - 이천희 교수님 강의 자료

 위와 같이 두 트랜잭션에서 서로 상대방이 나중에 원하는 자원에 대해 먼저 선점 후 나중에 서로 선점한 자원에 대해 락을 기다리게 되면 데드 락이 발생하게 된다.

 

 위 예시의 경우 T1은 Y에 대해, T2는 X에 대해 공유 락(read_lock)을 걸었다. 결과적으로 X와 Y는 조회만 할 수 있게 되었고 unlock 할 때까지 배타 락(write_lock)은 획득하지 못하게 된다. 그런데 두 트랜잭션 모두 unlock 전에 서로 이미 공유 락으로 선점하고 있는 자원(T1은 X 배타락, T2는 Y 배타락을 원함)에 대해 배타 락 획득을 원하고 있다. 이렇게 데드 락이 발생하게 되었다.

데드 락을 해결하려면?

 

 트랜잭션에서 락의 획득 순서를 일관되게 함으로써 데드 락을 해결할 수 있다. 예를 들어 위 두 트랜잭션에서도 Y -> X 또는 X -> Y 순서로 락을 일관되게 획득하게 하면 데드락이 발생하지 않는다. 혹은 락에 타임아웃을 설정함으로써 데드 락을 해결할 수 있다.