![]()
1. 들어가며지난 글에서는 선착순 승인 시스템에서 발생한 Race Condition 문제를 분석했습니다. 정원 10명인 모임에서 20명이 동시에 승인되는 심각한 정합성 문제였습니다.원인은 명확했습니다:Check-Then-Act 패턴: 정원 검사와 승인 사이의 시간 차비원자적 연산: currentMembers++가 DB 수준에서 원자적이지 않음트랜잭션 격리 수준의 한계: 다른 트랜잭션의 변경을 읽지 못함오늘은 JPA의 비관적 락(Pessimistic Lock)을 적용하여 이 문제를 해결하는 과정을 공유합니다. 2. 비관적 락(Pessimistic Lock)이란?개념비관적 락은 "충돌이 발생할 것"이라고 비관적으로 가정하고, 데이터를 읽는 시점에 락을 거는 방식입니다.DB 수준에서 SELECT ... FOR..
![]()
1. 들어가며현재 개발 중인 지역 기반 소셜 커뮤니티의 "소 모임" 서비스에서 인원이 제한된 모임에 참가자를 승인하는 기능을 제공하고 있습니다.서비스의 핵심은 정해진 인원 내에서만 사용자를 승인해야 한다는 점이였습니다. 로컬 환경에서의 단일 요청 테스트는 문제가 없었지만, 실제 운영 환경과 유사한 동시성 테스트를 진행하던 중 정합성 문제를 발견했습니다.오늘은 선착순 승인 시스템에서 발생한 Race Condition(경쟁 상태) 문제와 이를 분석한 과정을 공유해 드리려고 합니다. 2. 문제 상황: 정원을 초과한 승인모임 서비스의 비즈니스 로직은 간단합니다. 현재 승인된 인원이 정원보다 적을 때만 모임 주최자가 승인을 수행합니다.하지만 부하 테스트 도중, 정원을 조과하여 승인이 이루어지는 현상을 목격했습니다..
