가장 먼저 문제 해결을 어떻게 할지, 아래 4가지 방식으로 분류했다.
@Async 단일 스레드 풀 이용)딸깍하면 바로 해결되는 가장 간단한 방식이지만 모든 요청을 순차처리 하기 때문에, (물풍선 요청을 싱글 스레드로 처리하는 셈) 좋은 해결책은 아니라는 생각이 들어 바로 후보에서 제외했다.
‘DB 관점이 아니라 설계적으로는 해결할 수 없을까?’ 라는 생각에 떠올린 방법이다.
동일한 유니크 제약 조건을 갖는 요청들만 순차적으로 처리할 방법을 고민하던 과정에서 떠올린 방식이다. 하지만 serializable과 비슷하게 모든 요청을 순차적으로 처리해야 한다는 점, 동기적으로 응답을 보내줘야 하는 현 요구사항과 맞지 않는 점을 토대로 바로 후보에서 제외했다.
그냥 DB에만 매몰되어 생각하지 않으려 했다 … 는 점
삽입 과정에서 동시 문제가 발생하기 때문에, 애초에 락을 걸 대상이 존재하지 않는다.
그래서 한 가지 떠올랐던 방식이 네임드 락이었다. 유니크 제약 조건을 기반으로 문자열 키를 생성하면 되지 않을까? 라는 생각이 들었다.
그런데 이 방식은 락을 직접 점유 ~ 릴리즈하는 과정을 코드 내에서 직접 제어해야 한다는 점에서 리소스 관리의 주의성이 필요해보였다. 그뿐만 아니라, 단순 조회 로직에서도 네임드 락으로 인해 순차처리가 일어나야 한다는 점에서, 현재 요구사항에는 동시성 제어의 범위가 커보였다.
따라서 이 방식도 일단 보류했다.
네임드 락을 보류해놓고, 현재 코드에서 DB 수준으로 해결하는게 좋을 것 같았다.
앞서 언급했던 것처럼 네임드락은 범위가 커서, 최대한 필요한 범위 만큼만 동시성을 제어하는게 좋다고 생각했기 때문이다.