<TIL> 86. 비관적 락(pessimistic lock), 낙관적 락(optimistic Lock)

DB 충동 상황 개선법

1. 테이블의 row에 접근 시 Lock을 걸고 다른 Lock이 걸려 있지 않을 경우에만 수정을 가능하게 할 수 있다.
2. 수정할 때 내가 먼저 이 값을 수정했다고 명시해 다른 사람이 동일한 조건으로 값을 수정할 수 없게 하는 것.

비관적 락(pessimistic lock)

비관적 락은 Repeatable Read 또는 Serializable 정도의 격리성 수준 제공

비관적 락 -> 트랜잭션이 시작될 때 Shared Lock or Exclusive Lock을 걸고 시작하는 방법

Shared Lock을 걸게 되면 write를 하기 위해서는 Exclucive Lock을 얻어야하는데 Shared Lock이 다른 트랜잭션에 의해 걸려있으면 해당 Lock을 얻지 못해 업데이트를 할 수 없음. 수정을 하기 위해서는 해당 트랜잭션을 제외한 모든 트랜잭션이 종료되어야 함.

이렇게 Transaction을 이용해 충돌을 예방하는 것이 바로 비관적 락(Pessimistic Lock)

낙관적 락(optimistic Lock)

낙관적 락은 DB 충돌 상황을 개선할 수 있는 방법 중 2번째인 수정할 때 내가 먼저 이 값을 수정했다고 명시해 다른 사람이 동일한 조건으로 값을 수정할 수 없게 하는 것.

위 flow를 통해 같은 row에 대해 각기 다른 2개의 수정요청이 있었지만, 1개가 업데이트 됨에 따라 version이 변경되어 뒤의 수정 요청은 반영X

이렇게 낙관적 락은 version과 같은 별도의 컬럼을 추가해 충돌적인 업데이트 막음.
version 뿐만 아니라 hashcode or timestamp를 이용하기도 함.

-> 낙관적 락은 구분 컬럼을 사용해 충돌 예방

낙관적 락은 트랜잭션을 필요로 하지않아, 성능적으로 비관적 락보다 더 좋지만,
롤백시에 충돌이 났다고 하면 해결방법은 개발자가 수동으로 롤백처리를 해줘야한다는 단점이 있다.