데이터베이스 Lock

Lock

Lock이란 트랜잭션이 동시에 실행되서 발생하는 동시성 문제를 해결하기 위해 동시성 제어를 위한 DB 의 장치이다. 레코드를 Lock 함으로써 다른 트랜잭션에서 업데이트는 못하고 읽기만 가능하다던가, 읽기도 불가능하게 하게 할 수도 있다. Lock 은 Shared Lock 과 Exclusive Lock 으로 나뉜다.

 

Shared Lock

Shared Lock은 해당 레코드를 조회만 타 트랜잭션에 허용하는 것이다. 이 락이 걸린 레코드 대상으로는 Select 만 할 수 있다. Update 하려면 Lock 이 해제될 때까지 기다려야 한다. 타 트랜잭션에서 Shared Lock 을 똑같이 설정할 수 있다. 하지만 Exclusive Lock 은 설정할 수 없다. 

 

SQL 문으로 다음과 같이 설정할 수 있다.

SELECT ... IN SHARE MODE

Spring Data JPA 에서는

@Lock(LockModeType.OPTIMISTIC)

 

Exclusive Lock

Exclusive Lock은 해당 레코드를 타 트랜잭션에서 조회도 막는다. 타 트랜잭션은 락이 해제될때까지 조회도 못하고 기다린다. 타 트랜잭션에선 Shared Lock 과 Exclusive Lock 둘 다 설정할 수 없다. 

 

SQL 문으로 다음과 같이 설정할 수 있다.

SELECT ... FOR UPDATE

Spring Data JPA 에서는

@Lock(LockModeType.PESSIMISTIC_WRITE)

 

 

Gab Lock

Gab Lock 은 MySQL InnoDB 에 있는 Lock 이다. 인덱스 테이블에 적용된다. Between 과 같은 범위 조회를 했을 때 범위 내 비어있는 인덱스에 대해서도 Lock을 거는 것이다. 보통 Lock 은 실제 존재하는 Index 에만 Lock이 걸리는 것과 다른 점이다.

 

Gab Lock 이 필요한 이유는 Phantom Read 문제를 방지하기 위해서다. InnoDB 에선 MVCC(Muti-Version Concurrency Control) 가 적용되기 때문에 일반적인 Select 조회에선 언두로그를 조회하기 때문에 팬텀리드가 발생하지 않는다. 하지만 Exclusive Lock 조회를 하는 경우에는 언두로그가 아니라 다른 트랜잭션들이 반영된 레코드를 조회하기 때문에 문제가 발생한다.

 

만약 Gab Lock 없을 땐 A 트랜잭션에서 처음 ID 1~10 Exclusive 조회를 한 다음 B 트랜잭션에서 ID 10으로 Insert 를 하고 A 트랜잭션에서 두번째 Excusive 조회를 했을 때 첫번째 조회 때 없었던 ID 10 레코드가 조회된다. Phantom Read 문제가 발생한다.

 

Gab Lock이 트랜잭션 A 조회할 때 적용되었다면 트랜잭션 B 에서 ID 10을 Insert 할 때 commit 이 적용이 안되고 기다리고 있는다. Gab Lock 을 설정한 트랜잭션 A가 마치면 트랜잭션 B가 적용된다. 

 

MySQL InnoDB 에선 MVCC 때문에 발생할 수 있는 팬텀리드 문제를 자동적으로 Gab Lock 정책을 통해  Reaptable Read 를 보장한다.