재고를 읽은 뒤 차감할 때 SELECT FOR UPDATE를 쓰면 어떤 경쟁이 줄고 어떤 문제는 남나요?

잠금 읽기는 읽은 행을 바탕으로 변경하는 동안 다른 쓰기와의 경쟁을 통제하는 방법입니다. 조회와 변경을 같은 트랜잭션에 두어야 하며, 문장 실행이 끝나자 자동 커밋하면 후속 차감까지 보호되지 않습니다.

동작 원리와 전제

재고 행을 잠근 뒤 현재 잔량을 검사하고 차감·커밋합니다. 다른 요청은 기다리거나 NOWAIT 같은 정책에 따라 실패할 수 있습니다. 실제 잠그는 행·인덱스·범위와 읽는 버전은 DB와 격리 수준에 따라 확인합니다. 존재하지 않는 행이나 조건 범위까지 보호된다고 일반화하지 않습니다.

선택과 실패 처리

간단한 잔량 조건이면 remaining > 0인 UPDATE와 영향 행 수 확인이 더 짧은 원자 경계가 될 수 있습니다. 여러 행을 잠가야 하면 일관된 순서로 잡고 외부 API를 기다리지 않습니다. SKIP LOCKED는 경쟁 행을 건너뛰므로 정확한 전체 목록 조회와 다른 의미입니다.

구체적인 사례와 검증

재고가 없을 때 만들어야 하는 행을 SELECT FOR UPDATE로 찾았다고 하겠습니다. 조회 결과가 없으면 잠긴 행도 없을 수 있어 다른 요청의 삽입을 막지 못합니다. 범위 잠금이 제공되는 격리인지, 고유 제약과 삽입 충돌로 보호할지 정해야 합니다. 잠금 읽기를 모든 문제의 만능 해법으로 쓰기보다 어떤 자원이 잠기는지 구체적으로 설명하겠습니다. 이미 행이 있는 경우에도 여러 상품의 재고를 반대 순서로 잠그면 데드락이 날 수 있습니다. 상품 ID순으로 획득하고 짧게 커밋하며 실패한 transaction 전체를 제한적으로 재시도합니다. 조회 잠금과 실제 변경의 transaction 경계가 코드에서 끊어지지 않는지도 확인합니다.

두 세션의 대기·timeout·취소·데드락을 재현하고 잠금 보유 시간을 관찰합니다. 잠금을 얻은 뒤 예외가 나도 rollback과 연결 반환이 수행되는지 확인합니다. 잠금이 있다는 사실보다 보호할 조건이 실제 접근 범위에 포함되는지가 핵심입니다.