DataBase Lock

데이터베이스 락
DB의 트랜잭션 처리의 순차성을 보장하기 위해 데이터 변경을 일시적으로 중지하는 것.
일반적으로 일관성과 무결성을 유지하기 위해 DB에서 사용하는 공통적인 방법이다.

락은 데이터베이스 뿐만 아니라 어플리케이션에서도 걸 수 있는데, 어플리케이션단에서 거는 락은 optimistic DB에서 거는 것은 perssimisitic락이다.

optimistic

• 낙관적 (충돌시 락) : 실제 데이터 베이스에 락을 걸지 않고 어플리케이션에서 데이터를 버전으로 관리해서 데이터베이스 충돌 관리
• 직접 만들기 쉬움 (JPA @Version 을 사용하면 사용가능)
• 실제 데이터베이스에 락을 걸지 않기 때문에 데드락 적음, 충돌이 빈번하지 않으면 성능 좋음
• 충돌을 인지하는 시점이 커밋 시점이므로, 충돌이 발생해서 롤백해야 한다고 했을 때,
  그 전에 수행했던 모든 동작이 롤백되어야 하므로 충돌시 오버헤드가 크다

perssimistic

• 비관적 (충돌 예상시 락) : 실제 데이터베이스에 락을 건다.
• DB에서 설정
• 충돌이 발생하는 시점을 바로 인지 하므로, 충돌이 발생했을 때, 낙관적 락보다 오버헤드가 덜하다 / 데이터 무결성을 지키기 용이하다.
• 락을 건다는 것 자체가 데이터 베이스 리소스를 사용하는 것이므로 충돌이 없으면 오버헤드 발생

락에대해 고민할 때 고려사항

• 충돌이 빈번한지

• 읽기 / 쓰기 연산의 비율

  	-> 일반적인 웹 어플리케이션은 읽기가 대부분이므로 웹 어플리케이션은 낙관적 lock을 사용한다.

그럼 DB에서 처리하는 락은 어떤 것들이 있을까?

perssimistic lock은 데이터베이스, 엔진마다 상이하기 때문에 MySQL의 InnoDB의 락에 대해 알아보자.

perssimistic 락에 대한 설명(InnoDB)

공통적으로

X락(exclusive)

• 동시에 같은 컬럼을 write할 때
• x락이 걸려있으면 다른 트랜잭션은 x, s 락 걸 수 없음
• 가장 높은 강도의 락

S락(shared)

• 여러 락 걸기 가능(read lock)
• share mode 명시하면 락
• 가장 낮은 강도의 락

외에도 update lock, intent lock이 있다.

InnoDB는 어떤 락 방식을 사용할까?

레코드락

• 인덱스를 잠군다.
• 인덱스가 없으면 custered index를 잠군다

gap lock

• index가 없는 부분에 대한 lock

데드락이 생기는 경우

• 서로 참조하는 테이블이 x락을 걸 경우

→ deadlock detection (작은 트랜잭션을 롤백)

→ lock wait timeout (일정시간 지나면 감지)

etc

• next key lock
• table lock
• …