Bug/200 참여신청 동시성 이슈

[jaylovegood]

✨ Feature PR (to dev)

🧪 로컬 테스트 여부 (작업자 체크)

• 로컬에서 Swagger 혹은 테스트 코드로 동작을 확인했습니다.

📄 documentation 최신화 여부

변경사항과 관련된 API의 swagger documentation이 실제 동작과 일치하는지 확인합니다.

• (작업자) 확인하였습니다.
• (리뷰어) 확인하였습니다.
  확인했는데 registration 도메인에 documentation 안된 부분이 너무 많아서 지금 당장 해결하기엔 제가 여력이 안 됩니다.. 이번 사이클 지나가고 나서 어차피 yaml로 바꿀거라 그때 건드려볼 수 있을 것 같습니다.

📌 작업 내용(what & why)

• 참여자 수 count 시 lock을 획득한 후 읽도록 하였습니다 (FOR SHARE).
  • 기존의 일반 SELECT COUNT() 쿼리는 REPEATABLE_READ 격리 수준을 존중하기 위해 트랜잭션 시작 시점의 스냅샷을 기준으로 일관된 데이터를 읽습니다.
  • 즉, 트랜잭션이 시작되고 count가 실행되기 전에 참여자 수가 업데이트되었다면, 그것이 반영되지 않은 (스냅샷에 있는) 이전 값을 읽게 됩니다.
  • FOR SHARE를 붙임으로써 스냅샷이 아닌 현 시점의 데이터를 읽게 됩니다.
• 동시성 이슈를 테스트하는 integration test 케이스를 추가하였습니다.

🔎 영향 범위

• 동시성 / 트랜잭션 처리 영향

🔥 관련 이슈

• closes 참여신청 동시성 이슈 #200

[uykhc]

Codex의 도움을 받아 작성한 리뷰인 점을 미리 밝힙니다..

• 락 순서 역전으로 데드락 가능성이 생겼습니다. RegistrationService의 create()는 이벤트 락 후(FOR UPDATE) 참가 row들에 FOR SHARE를 걸고, delete()는 등록 row를 먼저 DELETE로 잠근 뒤 reconcileWaitlist()에서 이벤트 락을 잡습니다. 현재의 로직에서는 create(event -> registrations)와 delete(registration -> event) 순서가 충돌합니다.
  참여 신청과 삭제가 동시에 일어날 때 문제가 발생할 수 있다고 합니다. 삭제 시에도 event 락을 먼저 획득하도록 lock order를 통일하면 좋을 것 같습니다.
• 동시성 테스트가 모든 요청 완료/성공을 엄격히 검증하지 않아, 타임아웃 및 일부 실패(데드락 재시도 실패)를 진단하기 어렵습니다. doneLatch.await(...) 반환값을 확인하지 않고, 각 요청도 status assertion이 없습니다.

[jaylovegood]

락 순서를 통일해서 지적해주신 데드락 가능성을 차단했으며, 동시성 테스트 케이스를 보완했습니다. 감사합니다!

[uykhc]

1. 락 순서 역전
2. 동시성 테스트 검증 부족

두 부분 작업하신 내용 확인했습니다!