강사님 락관련 질문있습니다.

안녕하세요. 갓다귀갓장국님^^

여러가지 경우가 있지만, 주문의 예를 들어들이자면,

고객이 주문을 완료하고 나면, 주문의 상태가 접수 대기 상태로 남게 됩니다.

이 접수 대기 상태에서 사장님은 주문을 접수완료 상태로 바꿀 수 있습니다.

그런데 주문 대기 상태에서 고객은 주문을 취소할 수 있습니다.

여기서 고객이 주문을 취소하는 동시에 사장님이 주문을 접수완료 상태로 변경한다면, 미묘한 차이가 발생합니다.

최악의 경우 고객은 주문 취소에 성공하고, 사장님도 주문을 접수완료 해버릴 수 있습니다.

그러면 체크를 하면 되지 않나요? 라고 하지만 바로 거기서 문제가 발생합니다.

사장님이 주문을 접수완료 처리하는 로직입니다.

접수 완료 로직

1. 데이터베이스에서 주문상태를 조회합니다. 결과 : 주문상태=접수대기

2.만약 주문상태가 접수대기라면 로직 진행, 아니면 예외 처리

3. 데이터베이스에 주문 상태를 접수 완료로 처리

이렇게 보면 맞는 것 같지만, 사실 2번과 3번 사이에서 고객이 주문을 취소해버리면 문제가 됩니다.

그래서 1번에서 주문의 상태를 조회할 때 데이터베이스에 주문의 상태를 변경하지 못하도록 락을 걸어버리면 문제가 해결됩니다.

그런데 또 한편으로 생각해보면, 이렇게 정말 동시에 같은 데이터를 변경할 확율은 거의 밀리초 단위로 사장님이 접수하면서 취소해야 하는데, 대부분의 애플리케이션에서는 문제가 발생활 확율이 매우 낮습니다.

락을 거는 것은 요즘 같은 실시간 애플리케이션에서는 여러가지 위험이 많습니다.(데드락 문제 등등)

그래서 각 데이터베이스 특성에 맞는 락 사용 방법을 명확하게 이해하고, 또 락이 걸린 로우를 조회했을 때 어떤 예외가 발생하는지 등등 다양한 테스트를 꼭 해보아야 합니다.

저는 가급적이면 락을 거는 방법은 피하고, 낙관적 락이나, CAS 스타일의 방식, 또는 RDB나 REDIS 등을 사용해서 해당 주문번호를 한번에 한명한 변경할 수 있도록 로직의 입구에서 막는 방법을 선호합니다.

JPA 락에 대한 더 자세한 내용은 JPA책 16장 트랜잭션과 락 부분을 참고해주세요^^

감사합니다.

답변 도움이 되었습니다 정말 감사합니다 ^^