[bug] 문제 등록이 커넥션 2개를 점유해 동시 요청 시 커넥션 풀이 고갈된다

[KiSeungMin]

⚙️ 어떤 버그인가요?

문제 등록 요청 하나가 순간적으로 DB 커넥션을 2개 요구합니다. 커넥션 풀 크기는 설정이 없어 Hikari 기본값인 10이라, 동시 등록이 늘어나면 풀이 고갈되고 요청이 connectionTimeout 기본값인 30초를 꽉 채운 뒤에야 처리됩니다.

원인은 커밋 이후에 도는 이벤트 리스너입니다.

// StudyRoomFeedService.java:100
@TransactionalEventListener(phase = AFTER_COMMIT)
@Transactional(propagation = REQUIRES_NEW)
public void handleActivity(StudyRoomActivityEvent event) { ... }

registerProblem 의 트랜잭션이 커밋된 직후, 그 커넥션이 아직 반납되기 전에 리스너가 REQUIRES_NEW 로 두 번째 커넥션을 요청합니다. 같은 구조가 두 곳에 있습니다.

• studyroom/service/StudyRoomFeedService.java:100 — 스터디룸 활동 피드
• problem/reminder/ProblemReviewReminderService.java:39 — 복습 리마인더 생성

더 나쁜 점은 handleActivity 가 예외를 catch (Exception e) { log.error(...) } 로 삼킨다는 것입니다. 커넥션을 못 얻어 실패해도 사용자에게는 정상 응답이 나가고, 피드 생성과 챌린지 완료 판정이 조용히 유실됩니다.

🔎 어떤 상황에서 발생한 버그인가요?

Given 같은 폴더에 문제를 등록하는 요청이 동시에 8건 들어오고
When 그 폴더를 삭제하는 요청이 겹치면
Then 등록 요청 6~7건이 각각 30.2초 걸린 뒤에야 완료됩니다.

스레드 덤프로 확인한 대기 지점은 행 잠금이 아니라 HikariPool.getConnection 이었습니다. 무관한 폴더를 삭제하면 200ms 로 끝나므로, 같은 자원을 두고 경합할 때 드러납니다.

동시 등록이 10건을 넘으면 폴더 삭제가 없어도 같은 고갈이 발생할 수 있습니다.

✅ 예상 결과

• 문제 등록 요청 하나가 커넥션을 두 개 잡지 않아야 합니다.
• 부가 작업(피드·리마인더)이 실패하더라도 조용히 사라지지 않고 관측 가능해야 합니다.

💡 검토할 만한 방향

세 가지가 있고 서로 배타적이지 않습니다.

1. 커넥션 풀 크기 명시 — 가장 빠른 완화책이지만 근본 해결은 아닙니다. 애플리케이션이 커넥션을 2배로 쓴다는 사실은 그대로 남습니다.
2. 부가 작업을 비동기로 분리 — 이미 RabbitMQ 를 쓰고 있으므로 피드 생성을 메시지로 넘기면 요청 스레드가 커넥션을 두 번 잡지 않습니다.
3. AFTER_COMMIT + REQUIRES_NEW 조합 재검토 — 원 트랜잭션에 합류시키면 커넥션은 하나로 끝나지만, 피드 생성 실패가 문제 등록을 롤백시키게 됩니다. 어느 쪽이 맞는지는 정책 판단입니다.

📌 발견 경위

PR #231 (테스트 전면 개선) 에서 동시성 경합 테스트를 작성하다 발견했습니다. 3회 연속 재현됐습니다.

인프라 설정과 트랜잭션 설계에 동시에 걸쳐 있어 해당 PR 에서는 수정하지 않고 이슈로 남깁니다.

[KiSeungMin]

#319 작업 중에 실측으로 확인했습니다

폴더 잠금 문제(#319)를 파다가 이 이슈의 근거가 나왔습니다.

• ProblemReviewReminderService.handleProblemCreated 가 AFTER_COMMIT + REQUIRES_NEW 라, 바깥 트랜잭션 커넥션을 쥔 채로 예약 INSERT 용 커넥션을 하나 더 빌립니다.
• 그래서 동시 등록이 풀 크기에 닿으면 폴더 삭제가 없어도 풀이 자기들끼리 막힙니다. 테스트에서 8건만 몰아 넣어도 "사용중 10, 유휴 0, 대기중 8" 상태가 되고 전부 30초를 채웁니다.
• 30초는 Hikari 기본 connection-timeout 입니다. [Fix] 폴더 삭제 잠금이 전역 장애로 번진다 - 등록이 60초 뒤 504 인데 저장은 되고 다른 사용자까지 실패한다 #319 에서 프론트가 dev 에서 잰 30.2초와 같은 값입니다.
• spring.datasource.hikari.maximum-pool-size 가 dev 와 prod yml 양쪽에 없어서 기본값 10 입니다. tomcat threads.max 는 50 이라 균형이 맞지 않습니다.

#322 는 이 부분을 건드리지 않았습니다. 알림 발송 경로를 비동기로 빼거나 등록 트랜잭션 안으로 넣는 변경이라 영향 범위를 따로 봐야 합니다.

같이 볼 것은 풀 크기 설정입니다. 운영 설정이 secret 으로 주입되므로 코드와 secret 을 함께 봐야 합니다.

[KiSeungMin]

배포 판단 (2026-09-19)

승민님이 이 상태로 운영 배포하기로 정했습니다. 커넥션 풀 크기 조정과 예약 생성 경로 변경은 보류하고 이 이슈로만 남깁니다.

알고 가는 위험입니다.

• 문제 등록 한 건이 커넥션을 두 개 씁니다. 복습 알림 예약이 ProblemReviewReminderService.java:40-48 에서 AFTER_COMMIT + REQUIRES_NEW 라, 바깥 트랜잭션 커넥션을 쥔 채 하나를 더 빌립니다.
• spring.datasource.hikari 설정이 dev 와 prod 어디에도 없어 풀은 기본값 10 입니다. tomcat threads.max 는 50 입니다.
• dev 실측(프론트 세션): 폴더 삭제 없이 동시 등록 12건만으로 500 세 건(30.5초), 504 아홉 건(60.3초)이 났고, 같은 시각 다른 계정의 GET /api/problems/user 도 500/30.26초였습니다. 30초를 넘겨 응답한 요청도 서버에는 저장돼 있었습니다.
• 구버전 앱은 30초에 끊으므로 사용자는 실패로 보고 다시 저장합니다. 같은 오답노트가 두 개 생깁니다.
• 이 경로는 main 에 없어서 이번 배포로 처음 생깁니다. 운영의 현재 등록 경로는 커넥션 하나입니다.

나중에 다룰 때 후보는 셋입니다.

1. 예약 생성을 커밋 후 비동기로 넘겨 커넥션을 동시에 두 개 잡지 않게 하기
2. maximum-pool-size 를 명시하기. 운영 yml 이 secret 으로 주입되므로 레포에 공통 application.yml 을 두거나 secret 을 고쳐야 합니다
3. 예약 생성을 등록 트랜잭션 안으로 합치기. 커넥션은 하나가 되지만 예약 실패가 등록을 롤백시킬 위험이 생깁니다

배포 후에는 등록 응답 시간과 커넥션 풀 대기, 그리고 30초 근처 응답이 있는지 보시면 됩니다.