여러 명의 라이더가 하나의 배달에 대해 동시에 배차 요청을 하는 상황이 있을 것입니다.
라이더A가 배달에 대해 배차 요청을 하고, 동시에 라이더B가 배달에 대해 배차 요청이 들어오게 된다면 다음과 같은 상황이 발생할 것입니다.
이 경우 라이더A가 배달에 대해 배차 요청을 하고 요청이 성공했다는 응답까지 받게 됩니다. 그러나 동시에 들어온 라이더B의 배차 요청으로 인해 라이더A의 갱신 내역은 사라지고 라이더B의 갱신 내역이 저장되게 됩니다. 이를 두 번의 갱신 분실 문제라 합니다.
이를 해결하기 위해서는 다음과 같은 방법이 있습니다.
기본적으로는 마지막 커밋만 인정하기가 사용됩니다. 하지만 배차 요청의 경우 마지막 커밋만 인정해서는 라이더 입장에서 어이없는 상황이 발생할 것입니다. 따라서 이 상황에서는 최초 커밋만 인정하는 것이 훨씬 합리적입니다.
저는 이 상황을 해결하기 위해 JPA가 제공하는 낙관적 락을 이용하였습니다. 본 게시글에서는 JPA의 낙관적 락과 이를 적용했을 때의 테스트 코드 작성 방법에 대해 다룹니다.
본격적으로 락을 적용하기에 앞서 락을 적용하지 않은 코드를 실행시키고 JMeter를 이용한 테스트를 돌려보면서 실제로 다수의 라이더가 한번에 배차 요청을 하는 경우 정말로 갱신 분실이 발생하는지 알아보겠습니다.
다음 서비스에서는 로그인한 라이더와 배차 요청한 배달을 저장소에서 불러온 뒤, 불러온 배달에 라이더 배정을 호출하면서 인자로 불러온 라이더를 넘겨줍니다.
배달은 이미 라이더가 배정되었는지 검증을 진행한 뒤 배정되었으면 예외를 던지고 아니면 파라미터로 전달된 라이더와 연관관계를 맺으면서 라이더의 배차 요청이 종료됩니다.
예외를 던지는 경우 컨트롤러 단에서 상태 코드가 409인 응답을, 정상이라면 204 응답을 반환할 것입니다.