🔐 JPA에서의 Lock 완전 정복!

우르의 Lock & JPA Lock 강의 정리

---

💡 Lock이란?

여러 커넥션이 동시에 동일한 데이터를 수정하려고 할 때, 데이터의 일관성을 지키기 위한 메커니즘입니다.

• 데이터를 잠궈(lock) 두면,
• 다른 트랜잭션은 접근 불가
• 연산이 끝나고 잠금 해제되면 다른 트랜잭션이 접근 가능

✅ 즉, 자물쇠처럼 데이터를 잠그고 푸는 과정이 Lock!

---

🔁 Lock vs Transaction

개념	설명
Lock	데이터 일관성을 위한 동시성 제어 수단
Transaction	작업의 원자성 보장 (all or nothing)
트랜잭션 격리 수준 (Isolation Level)	여러 트랜잭션 간 상호 간섭을 얼마나 허용할지에 대한 전략
🔑	Lock은 이 격리 수준을 구현하는 방법 중 하나

---

✌️ 낙관적 Lock (Optimistic Lock)

“충돌이 잘 안 날 거야”라는 낙관적인 가정

• 버전 기반으로 충돌 확인
• 트랜잭션 충돌이 발생한 후에 처리
• Application 수준 Lock이라고도 불림

✅ JPA에서 사용하기

@Version
private Long version;

💡 특징

• 업데이트 시 버전 불일치 ➡️ 예외 발생
• 성능에 유리 (락을 잡지 않음)
• 대신 충돌 시 롤백 및 재시도 필요

---

😬 비관적 Lock (Pessimistic Lock)

“항상 충돌이 날 거야”라는 비관적인 가정

• 데이터를 읽는 순간부터 잠금
• DB 수준 Lock
• 대표 예: SELECT ... FOR UPDATE

✅ JPA에서 사용하기

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("select c from Coupon c where c.id = :id")
Optional<Coupon> findByIdForUpdate(Long id);

💡 특징

• 다른 트랜잭션이 접근하지 못함
• 정확한 처리 가능하지만 성능 저하 가능

---

🧪 실전 예제 – 쿠폰 발급 시나리오

🎯 목표

• 쿠폰 총 5개
• 동시에 20명이 발급 요청

🔓 Lock 미적용

• 20명 모두 발급 성공 ❌ (동시성 문제)

---

✅ 낙관적 Lock 사용

• @Version 필드로 충돌 감지
• 버전이 일치해야 업데이트 성공
• 실제 결과: 3개 발급만 성공
  → 나머지는 버전 충돌로 실패

---

✅ 비관적 Lock 사용

• @Lock(LockModeType.PESSIMISTIC_WRITE) 사용
• 트랜잭션 하나가 처리 중이면 다른 트랜잭션은 대기
• 실제 결과: 정확히 5개 발급

---

🤔 언제 어떤 Lock을 써야 할까?

조건	추천 Lock 방식
충돌 가능성 낮음	✅ 낙관적 Lock
충돌 가능성 높음, 정확한 처리 필요	✅ 비관적 Lock
재시도 로직이 구현되어 있음	낙관적 Lock 사용해도 OK
처리량보다 정합성이 더 중요	비관적 Lock 고려

---

📝 마무리 정리

구분	낙관적 Lock	비관적 Lock
충돌 가정	잘 안 난다	자주 난다
사용 위치	애플리케이션 (버전 기반)	DB (잠금 기반)
성능	우수	낮음 (트랜잭션 대기)
처리 실패 시	예외 발생, 재시도 필요	트랜잭션 대기

---

📌 추천: 실무에서는?

• 기본은 낙관적 Lock 사용
• 중복 발급, 재고 차감, 정산처럼 정합성이 중요한 부분에는
  → 비관적 Lock을 적용하는 것도 고려해야 합니다!