낙관적 락, 비관적 락

낙관적 락

DB 락 안 걸고, 엔티티에 @Version 칼럼으로 수정 시점에 충돌 감지.
읽기 많고 수정 충돌 드문 서비스(피드나 게시글 카운트 같은거) 확장성 중요할 때 쓰자
고성능이니까 알아서 적절히 쓰면 좋음
하지만 저장 시점에만 충돌이 드러나니까 재시도 로직을 넣고 대량 동시 갱신엔 부족하다.
JPA에서는 #@Version 한 칼럼만 추가하면 작동
OptimisticLockException/ObjectOptimisticLockingFailureException 발생.
벌크 업데이트는 버전 무시하므로 금지하던가 후처리 하던가

비관적 락

그냥 잠금

수정 가능성 있으면 아예 DB 레벨ㄹㅎ 락을 걸어 다른 트랜잭션 접근 차단.
충돌이 잦고, 금액/재고 같은 정합성 최우선 일떄 쓰자
충돌을 사전에 차단 해서 실패, 재시도 줄어둘지만 느릴 수 있고 데드락, 타임아웃 관리가 필요하며 커넥션 오래 점유 금지 해야 하니 알아서 적절하게 쓰자!

읽기 락 = 공유 락

읽는 동안 누가 바꾸면 안되게 하기

여러 트랜잭션이 릭는 동시 가능하지만, 수정은 블록
읽기 중에 값이 흔들리면 안 되는 보고서/정산/검증 단계에서 쓰자
읽기 안정성이 확보되지만 트랜잭션이 줄서기 시작하면 전체 처리량 저하 되고 일부 DB/격리레벨 조합에선 팬텀/스냅샷 읽기가 더 낫기도

쓰기 락 = 배타 락

누가 수정하고 있으면 아무도 접근 못하게 함

대상 행에 단독 접근. 다른 트랙잭션의 읽기,쓰기 모두 대기 또는 차단.
재고 차감, 포인트 정산, 좌석 예약처럼 경합 높은 갱신 에서 쓰자!
가장 강력한 정합성 보장하지만 락 경합이 높아지면 대기, 타임아웃, 데드락 위험이 커지고 락 범위,시간 최소화가 중요해진다