락이 있어야 하는 상황
- 게시글에 좋아요를 업데이트한다.
- A라는 사람과 B라는 사람이 동시에 좋아요를 눌렀다.
- A라는 사람이 조회를 하고 입력하는 동안(좋아요수 300)
- B라는 사람이 입력이 끝나기 전에 조회를 한다(좋아요수 300)
- A라는 사람이 조회하고 300의 +1의 값을 하여 301가 값이 된다.
- B라는 사람이 조회해서 가지고온 값 300의 +1인 301의 값이 된다.
- A라는 사람의 쓰레드에서 301로 update한다
- B라는 사람의 쓰레드에서 301로 update한다.
302가 되었어야했지만 301이 되는 상황이 벌어지고 한사람은 자신이 한개 아니게 될 수 도 있다. 참고로 이때. 좋아요를 누른사람을 기록해 주지 않는 다는 전제하이다.
이 때 필요한 것이 락(lock)이다.
락이란?
앞서 이야기한 상황을 방지하기 위해서, A라는 사람이 게시 글 좋아요수에 접근하고 있는 상황(Update까지 끝내기 전)에서는 B라는 사람이 게시 글 좋아요수에 접근하지 못하도록 막는 것이다.
락에는 종류가 2가지가 존재한다.
- 낙관적 락
- 비관적 락
락에 대해서 살펴보자.
낙관적 락(Optimistic Lock)이란?
데이터 갱신 시, 총돌이 발생하지 않을 것이라는 가정을 두고 진행하는 락 기법이다.
걸어잠그어 접근을 못하게 하기 보다는 충돌을 방지하기 위한 방법이다.
비관적 락(Pessimistic Lock)이란?
데이터 갱신 시, 충돌이 발생할 것이라는 가정을 두고 진행하는 락 기법이다.
걸어잠그어 접근을 못하게 하는 것이 핵심이다.
JPA에서의 락
JPA에서는 락에 대해서 많은 지원이 된다. 하나씩 살펴보자.
JPA 낙관적 락
JPA는 낙관적 락을 "Version"을 이용하여 제공한다.
Version이라는 속성을 이용하여 접근 자체에 Version을 체크하여 충돌이 되었는지 확인할 수 있다.
@Version
private Long like;낙관적 락 고찰
낙관적 락과 같은 경우는 1000개의 요청이 존재한다면, 가장 처음의 1개는 적용되고 나머지 999개는 버전 변경이 맞지않아서 롤백된다. 그만큼 자원 소모가 발생한다.
모든 작업이 수행되고, commit 하는 시점에 충돌 여부를 알 수 있기 때문에 느리게 될 경우가 존재한다.
JPA 비관적 락
JPA는 "@Lock" 어노테이션을 통해 비관적 락을 지원한다.
@Lock(LockModeType.PESSIMISTIC_WRITE)
Optional<Board> findBylike(Long id);비관적 락 고찰
레코드 자체에 락을 걸기 때문에 줄을 서야한다. 그만큼 병목현상이 생길 수 있다.
요약
위와 같이 락이라는 것이 필요 할때가 있다. 하지만 락을 사용하면 그 만큼 동시 처리가 되지 못하여 시간이 걸릴 수 있기때문에 사용처를 잘 고민하여 사용해야한다.
