fix: 모임 지원 락킹 테스트가 간헐적으로 깨지는 문제 #772
Description
📜 Bug Description
🧪 테스트 개요
MeetingV2ConcurrencyTest
“동일 사용자가 동시에 여러 신청을 시도할 경우 오직 하나만 성공해야 한다”
- 기대값: 동시 요청 5개 중 1개 성공 / 4개 실패
- 실제 결과: 간헐적으로 2개 이상 성공
❗ 문제 요약
CI 환경에서 테스트가 비결정적으로 실패함
→ 원인은 Application Lock과 DB Transaction 격리 수준 간의 불일치로 추측됨
🧠 근본 원인 분석
🔒 현재 동시성 제어 방식
UserLockManagerConcurrentHashMap<Integer, ReentrantLock>기반- JVM In-Memory Lock
- 트랜잭션 커밋 시점과 동기화되지 않음
⚠️ 문제 발생 시나리오
┌─────────────────────────────────────────────────────────────────────┐
│ Thread 1: lock → SELECT(0건) → INSERT → [COMMIT 전] → unlock │
│ Thread 2: lock 획득 → SELECT(0건, T1 미커밋) → INSERT → COMMIT ❌ │
└─────────────────────────────────────────────────────────────────────┘
- PostgreSQL 기본 격리 수준: READ COMMITTED
- 커밋되지 않은 데이터는 다른 트랜잭션에서 조회 불가
- Thread 2는 Thread 1의 INSERT를 보지 못해 중복 INSERT 발생
🐞 Bug Condition
| 조건 | 설명 |
|---|---|
| 동시 요청 | 동일 사용자가 밀리초 단위로 여러 요청을 동시에 전송 |
| CI 환경 | GitHub Actions 러너 (로컬과 다른 CPU 스케줄링) |
| DB 격리 수준 | PostgreSQL READ COMMITTED |
| 락 범위 문제 | UserLockManager.unlock() 이후 @Transactional 커밋까지의 공백 |
| 재현 빈도 | 테스트 10회 반복 시 1~2회 실패 |
| 발생 환경 | CPU 자원이 제한된 CI 환경에서 빈도 증가 |
📷 실패 로그
MeetingV2ConcurrencyTest > 모임 지원 락킹 테스트 >
동일 사용자가 동시에 여러 신청을 시도할 경우 오직 하나만 성공해야 한다 FAILED
org.opentest4j.AssertionFailedError:
expected: 1
but was: 2
at MeetingV2ConcurrencyTest.java:151