동시성 제어 Chap 1 | 비관적 락, 낙관적 락 ?

대량의 트래픽을 핸들링하기 위한 동시성 제어 기법 중 여러가지 방법이 있는데

그중에서 비관적 락과, 낙관적 락 두 락의 차이를 알아보자 👀

 

---

비관적락

: 자원 요청에 따라서 동시성 문제가 발생할것이라고 사전에 예측하고, 락을 걸어버리는 방법론

: 트랜잭션의 충돌이 발생한다고 가정하고 하나의 트랜잭션이 자원에 접근시 락을 걸고, 다른 트랜잭션이 접근하지 못하도록 함 

: 데이터베이스에서 Shared Lock(공유, 읽기 잠금), Exclusive Lock(배타, 쓰기 잠금)을 건다.

 

1. Shared Lock

- 접근한 트랜잭션이 작업중일 때 다른 트랜잭션에서는 읽기만 가능하고, Exclusive Lock 적용이 불가능하다. 

 

 

2. Exclusive Lock

- 접근한 트랜잭션이 작업중일 때 다른 트랜잭션에서는 읽기/쓰기가 모두 불가능하고 Shared/Exclusive Lock 적용이 추가적으로 불가능

public interface BoardRepository extends JpaRepository<Board, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("select b from Board b where b.id = :id")
    Board findByIdForUpdate(Long id);
}

*/ LockMode 종류 

LockModeType.PESSIMISTIC_WRITE
- 일반적인 옵션. 데이터베이스에 쓰기 락
- 다른 트랜잭션에서 읽기도 쓰기도 못함. (Exclusive lock)

LockModeType.PESSIMISTIC_READ
반복 읽기만하고 수정하지 않는 용도로 락을 걸 때 사용
다른 트랜잭션에서 읽기는 가능함. (Shared Lock)

LockModeType.PESSINISTIC_FORCE_INCREMENT
Version 정보를 사용하는 비관적 락

 

3. 장점과 단점

 

: 비관적 락 자체는 로우 자체에 락을 실제로 설정함으로 성능상 문제가 발생할 수 있음

: 충돌이 자주 발생하는 환경에서 롤백의 횟수를 줄일 수 있고, 데이터 무결성을 보장하는 수준이 매우 높음!

 

---

낙관적락

: 자원에 락을 걸어서 선점하는 방식이 아닌, 동시성 문제가 발생하면 그때 처리하자! 는 낙관적 처리 기법

: 트랜잭션이 충돌이 발생하지 않을것이라는 가정을 하여 충돌을 막지않고 충돌이 난것을 감지하면 그때 처리

: 데이터베이스가 제공하는 락 기능을 사용하지않고(DB단에서 동시성 처리X) JPA가 제공하는 버전 관리 기능을 사용함 

   => version의 상태를 보고 충돌을 확인하며 충돌이 확인된 경우 Rollback 하는 방식으로 처리

 

 

@Entity
public class Board {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    @Version						// 엔티티를 수정할 때 마다 버전이 증가함
    private Long version;
}

1. 장점과 단점

 

: 충돌이 나지 않는다는 가정하에 동시 요청에 대해 처리 성능이 좋음

: 잦은 충돌이 일어나는 경우 롤백 처리에 대한 비용(요청이 실패할 경우 개발자가 직접 롤백처리를 해야함)이 많이 들어 손해가 발생함

: 트랜잭션을 커밋하기전에는 충돌 여부를 알 수 없음