비관적 락(Pessimistic Lock)과 낙관적 락(Optimistic Lock) 차이 with JPA

1. 비관적 락(Pessimistic Lock)

특징:

• 데이터에 대한 충돌이 빈번할 것으로 예상될 때 사용하는 방법.
• 데이터가 다른 트랜잭션에 의해 변경되지 않도록 **락(Lock)**을 이용해 강제적으로 제어.
• 데이터에 접근하려는 시점에 바로 락을 걸어서 다른 트랜잭션이 데이터를 읽거나 수정하지 못하게 한다.
• 데이터의 일관성을 보장하지만, 성능에 영향을 줄 수 있음.

장점:

• 데이터 충돌 가능성을 완벽히 방지.
• 데이터의 신뢰성이 중요하거나 다수의 사용자 간 충돌이 예상될 때 적합.

단점:

• 락을 사용하기 때문에 성능이 저하될 가능성이 있음.
• 데드락(Deadlock) 상황이 발생할 수 있음.

JPA에서의 사용: JPA에서는 @Lock 어노테이션과 엔티티 매니저의 lock() 메서드를 통해 비관적 락을 구현합니다.

 

@Lock(LockModeType.PESSIMISTIC_WRITE) // 쓰기 락 (다른 트랜잭션의 읽기/수정 불가)
@Query("SELECT u FROM User u WHERE u.id = :id")
User findByIdWithPessimisticLock(@Param("id") Long id);

 

 

---

2. 낙관적 락(Optimistic Lock)

특징:

• 데이터에 대한 충돌이 적을 것으로 예상될 때 사용하는 방법.
• 트랜잭션이 데이터를 수정하는 시점까지 충돌을 고려하지 않다가, 커밋 시점에서 충돌을 검사.
• 보통 버전 번호나 타임스탬프를 사용해 변경 여부를 확인.

장점:

• 락을 사용하지 않아 성능이 뛰어남.
• 동시성이 높은 시스템에서 유리함.

단점:

• 충돌이 발생하면 해당 트랜잭션을 재시도해야 함.
• 데이터 변경 충돌이 빈번하다면 성능이 저하될 수 있음.

JPA에서의 사용: JPA에서는 @Version 어노테이션을 사용해 낙관적 락을 구현합니다.

 

@Entity
public class User {
    @Id
    @GeneratedValue
    private Long id;

    @Version
    private Integer version; // 버전 필드
}

 

JPA는 엔티티의 @Version 필드를 사용해 데이터가 변경되었는지 확인합니다. 트랜잭션 커밋 시, DB에 저장된 버전과 엔티티의 버전을 비교해 충돌 여부를 판단합니다.

실생활 예제:

• 쇼핑몰의 상품 수량 관리: 한 사용자가 상품 정보를 변경하는 동안 다른 사용자가 동시에 작업을 시도하면, 나중에 작업한 사용자는 충돌로 인해 재시도하게 됨.
• 협업 문서 편집: 여러 사용자가 문서를 편집할 때, 변경 충돌이 발생하면 해당 사용자에게 알려줌.

---

3. 비교 및 선택 기준

특징비관적 락낙관적 락

충돌 가능성	높음	낮음
성능	상대적으로 낮음	상대적으로 높음
충돌 처리	충돌 발생 전 방지	충돌 발생 후 처리
사용 사례	은행 시스템, 티켓 예매	협업 시스템, 상품 수량 관리

---

4. 실생활과 JPA를 연계한 시나리오

예제 시나리오: 티켓 예매 시스템

• 비관적 락: 사용자가 특정 좌석을 예매할 때 해당 좌석 데이터에 비관적 락을 걸어 다른 사용자가 접근하지 못하도록 한다.

예:

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT t FROM Ticket t WHERE t.id = :id")
Ticket findTicketWithPessimisticLock(@Param("id") Long id);

 

낙관적 락: 사용자가 예매 중인 좌석 데이터는 자유롭게 조회가 가능하며, 커밋 시점에 충돌 여부를 확인.

예:

@Entity
public class Ticket {
    @Id
    private Long id;

    @Version
    private Integer version; // 낙관적 락을 위한 버전 필드
}