DELETE , UPDATE 쿼리 관련 동시성 문제

문제점 :

상품을 작성하던 중 PAGIGNG 혹은 조회 과정에서 글이 삭제 되거나 , 수정되었을 때는 어떻게 진행할지에 대한 의견이 나왔다.

단순히 상품, 전체 만을 조회 할 때는 글이 삭제 수정되는 것만으로 그칠 수 있는 문제지만 후에 해당 상품을 구매하는 경우에는 구매 도중 글을 삭제하거나 취소할 수 있다는 문제까지 유발 될 것으로 예측되어 해당 부분에 대한 고민을 생각했다.

생각한 해결방안 :

1. 각 요청시마다 검사

• 너무 많은 요청과 잦은 검사가 필요하게 된다.
• 또한 DATA의 문제를 BACKEND단에서 모두 검증하는 방식이, DATA는 DB영역에서 관리하고 서비스는 BACKEND 영역에서 관리하는 분리에 대한 개념에서 벗어났다고 느꼈다.

1. 낙관적 LOCK(S-LOCK)

• 구매 과정에서, 특히 DB의 VERSION 검증 과정에서 많은 시간이 필요할 것이라고 판단하였다.
• 구매까지 고려했을 때, X-LOCK에 비해 안정성이 떨어질 것이라고 생각했다.

1. 비관적 LOCK(X-LOCK)

• DELETE, UPDATE 요청 시 해당 요청에 대해 LOCK을 걸고, 다른 트랜잭션은 대기한다(X-LOCK)
• 사실 조회 자체만 고려하면, MYSQL의 기본인 repetable read 만으로 충분할 수 있지만, 구매 요청까지 고려하면 X-LOCK의 사용이 더 의미있다고 판단했다.

결정 :

상품 구매와 판매까지 고려하였을때, X-LOCK을 사용하는 방안이 가장 옳다고 판단하였다.

하지만, X-LOCK 사용으로 인한 추가 고안해야할 사항도 존재한다.

DELETE 요청이 곧 조회 , 혹은 구매 시 대기 시간에 영향을 끼치게 되는 문제가 발생하여 DELETE 수를 최대한 줄여야 한다고 생각하게 되었다.

DELETE 횟수를 줄여야 한다.

• 기존엔 판매완료시 모두 삭제를 진행하는 형태로 생각하여 STATUS를 BOOELAN 값으로 단순하게 판단하였다.
• STATUS를 판매중, 판매완료, 상품만료로 변경하여 만료 혹은 상품판매시도 DELETE 요청을 보내지 않는, DELETE 요청이 본인이 직접 글을 삭제할때만 이루어지는 형태로 변경하여 DELETE수를 감소시켰다.
• 이를 통해 수정과 삭제시는 X-LOCK을 걸고, 해당 LOCK이 걸리는 횟수를 최소화 하는 방식으로 결정하게 되었다.