fix(pose): 재전송 데드락의 근본 처방 — savePoseDataBatch 를 READ COMMITTED 로 (#276)

backend/src/main/java/com/shadowfit/service/exercise/PoseDataService.java

@@ -21,6 +21,7 @@
 import org.springframework.jdbc.core.BatchPreparedStatementSetter;
 import org.springframework.jdbc.core.JdbcTemplate;
 import org.springframework.stereotype.Service;
+import org.springframework.transaction.annotation.Isolation;
 import org.springframework.transaction.annotation.Transactional;
 import org.springframework.transaction.support.TransactionSynchronization;
 import org.springframework.transaction.support.TransactionSynchronizationManager;
@@ -87,8 +88,19 @@ public class PoseDataService {
      * 저장 전 다운샘플(위치 B: Spring, pose-ingest-downsampling.md §3-B) — 라이브 분석
      * (DTW·sync·rep 감지)은 이 저장 이전 FastAPI에서 이미 끝난 값이라 저장본을 줄여도 영향 없고,
      * 영향받는 건 리포트 시계열 해상도뿐(같은 문서 §1 안전판).
+     *
+     * <p><b>격리수준 READ COMMITTED (#276, 2026-09-24 사용자 confirm).</b> 기본 RR 에서는 중복 키
+     * 한 건(재전송이 원본과 겹칠 때)이 {@code PRIMARY} 의 파티션 끝(supremum)에 X 락을 잡아, 커밋까지
+     * 같은 파티션의 <b>모든 신규 삽입</b>을 세우고 두 재전송이 겹치면 데드락이 된다. RC 에서는 그 락이
+     * 안 생긴다 — 결정적 재현과 동시 부하(워커 8, 중복)에서 RR 45.9% → RC 0/960
+     * ({@code loadtest/results/r276-lock-trace-2026-09-24/}). 중복 검사가 uk 원본 레코드에 잡는
+     * next-key 락은 RC 에서도 남아 <b>한 방향 대기</b>는 생길 수 있다 — 세션 키가 {@code session_id}
+     * 로 묶여 있어 순환이 안 닫힌다는 것이 근거이고, 한 트랜잭션이 여러 세션 키를 섞게 되면 다시 볼 것.
+     * 아래 세션 조회는 잠금 없는 읽기 한 번이라 RC 로 바뀌어도 보장이 달라지지 않는다.
+     * 데드락 재시도({@code ExerciseGrpcService})는 다른 원인에 대한 그물로 그대로 둔다.
+     * 분기와 기각된 대안: docs/decisions/r276-lock-root-cause-fix.md
      */
-    @Transactional
+    @Transactional(isolation = Isolation.READ_COMMITTED)
     public void savePoseDataBatch(Long sessionId, List<com.shadowfit.grpc.PoseDataRequest> grpcList) {
         if (grpcList == null || grpcList.isEmpty()) return;
 

backend/src/test/java/com/shadowfit/service/exercise/PoseDataResendDeadlockRaceTest.java

@@ -0,0 +1,166 @@
+package com.shadowfit.service.exercise;
+
+import com.shadowfit.grpc.PoseDataRequest;
+import com.shadowfit.model.exercise.Category;
+import com.shadowfit.model.exercise.Exercise;
+import com.shadowfit.model.exercise.Session;
+import com.shadowfit.model.exercise.Status;
+import com.shadowfit.model.member.Member;
+import com.shadowfit.model.member.UserRole;
+import com.shadowfit.repository.exercise.CategoryRepository;
+import com.shadowfit.repository.exercise.ExercisesRepository;
+import com.shadowfit.repository.exercise.SessionRepository;
+import com.shadowfit.repository.member.MemberRepository;
+import com.shadowfit.support.MySqlContainerSupport;
+import org.junit.jupiter.api.AfterEach;
+import org.junit.jupiter.api.DisplayName;
+import org.junit.jupiter.api.Test;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.dao.PessimisticLockingFailureException;
+import org.springframework.jdbc.core.JdbcTemplate;
+import org.springframework.test.context.ActiveProfiles;
+
+import java.math.BigDecimal;
+import java.time.LocalDateTime;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.concurrent.ConcurrentLinkedQueue;
+import java.util.concurrent.CountDownLatch;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import static org.assertj.core.api.Assertions.assertThat;
+
+/**
+ * 재전송이 원본과 겹칠 때의 데드락 (#276) — {@code savePoseDataBatch} 를 RC 로 돌린 처방의 회귀 가드.
+ *
+ * <p><b>무엇을 고정하나.</b> 기본 RR 에서는 중복 키 한 건이 {@code PRIMARY} 의 파티션 끝(supremum)에
+ * X 락을 잡고, 서로 다른 세션의 재전송이 동시에 겹치면 그 X 를 둘이 쥔 채 서로의 insert intention 을
+ * 기다려 데드락이 된다(결정적 재현: {@code loadtest/results/r276-lock-trace-2026-09-24/}). 같은 모양을
+ * 서비스 경로로 건다 — 세션 {@value #SESSIONS} 개가 각자 같은 배치를 {@value #RESENDS} 번(첫 번만 신규,
+ * 나머지는 전부 중복) 동시에 보낸다.
+ *
+ * <p><b>왜 «0» 을 단언할 수 있나.</b> 같은 모양의 SQL 판에서 RR 은 문장당 약 46%, RC 는 0/960 이었다.
+ * 이 테스트는 {@value #SESSIONS} × {@value #RESENDS} 번을 부르므로 RR 로 되돌리면 사실상 반드시 걸린다
+ * (2026-09-24, 격리수준을 빼고 돌려 실패하는 것을 확인했다). 데드락 재시도는 {@code ExerciseGrpcService}
+ * 에 있고 이 테스트는 서비스를 직접 부르므로, 여기서 잡히는 것은 재시도로 가려지기 전의 데드락이다.
+ *
+ * <p>H2 는 이 잠금을 재현하지 못한다 — 실 MySQL({@link MySqlContainerSupport})에서만 돈다.
+ */
+@SpringBootTest
+@ActiveProfiles("race")
+@DisplayName("pose 재전송 데드락 (#276)")
+class PoseDataResendDeadlockRaceTest extends MySqlContainerSupport {
+
+    private static final int SESSIONS = 8;
+    private static final int RESENDS = 20;
+    private static final int FRAME_COUNT = 50;   // DOWNSAMPLE_WINDOW=5 → 10행
+
+    @Autowired private PoseDataService poseDataService;
+    @Autowired private ExercisesRepository exercisesRepository;
+    @Autowired private CategoryRepository categoryRepository;
+    @Autowired private MemberRepository memberRepository;
+    @Autowired private SessionRepository sessionRepository;
+    @Autowired private JdbcTemplate jdbcTemplate;
+
+    private Long memberId;
+    private final List<Long> sessionIds = new ArrayList<>();
+
+    @AfterEach
+    void tearDown() {
+        for (Long id : sessionIds) {
+            jdbcTemplate.update("DELETE FROM pose_data WHERE session_id = ?", id);
+            jdbcTemplate.update("DELETE FROM exercise_sessions WHERE id = ?", id);
+        }
+        if (memberId != null) {
+            jdbcTemplate.update("DELETE FROM users WHERE id = ?", memberId);
+        }
+    }
+
+    @Test
+    @DisplayName("서로 다른 세션의 중복 재전송이 동시에 겹쳐도 데드락이 나지 않고, 멱등은 유지된다")
+    void concurrentDuplicateResendsDoNotDeadlock() throws Exception {
+        seedSessions();
+        List<PoseDataRequest> batch = frames();
+
+        ExecutorService pool = Executors.newFixedThreadPool(SESSIONS);
+        CountDownLatch start = new CountDownLatch(1);
+        AtomicInteger deadlocks = new AtomicInteger();
+        ConcurrentLinkedQueue<Throwable> others = new ConcurrentLinkedQueue<>();
+
+        for (Long sessionId : sessionIds) {
+            pool.submit(() -> {
+                start.await();
+                for (int i = 0; i < RESENDS; i++) {
+                    try {
+                        poseDataService.savePoseDataBatch(sessionId, batch);
+                    } catch (PessimisticLockingFailureException e) {   // 데드락·락 대기 초과의 공통 조상
+                        deadlocks.incrementAndGet();
+                    } catch (Throwable t) {
+                        others.add(t);
+                    }
+                }
+                return null;
+            });
+        }
+        start.countDown();
+        pool.shutdown();
+        assertThat(pool.awaitTermination(120, TimeUnit.SECONDS)).as("시간 안에 끝나야 한다").isTrue();
+
+        assertThat(others).as("데드락 외 예외는 없어야 한다").isEmpty();
+        assertThat(deadlocks.get())
+                .as("RR 로 되돌리면 중복 한 건이 파티션 끝을 잠가 여기서 걸린다 — %d/%d",
+                        deadlocks.get(), SESSIONS * RESENDS)
+                .isZero();
+
+        for (Long sessionId : sessionIds) {
+            Integer rows = jdbcTemplate.queryForObject(
+                    "SELECT COUNT(*) FROM pose_data WHERE session_id = ?", Integer.class, sessionId);
+            assertThat(rows).as("세션 %d: 재전송 %d번이 한 벌로 접혀야 한다", sessionId, RESENDS)
+                    .isEqualTo(FRAME_COUNT / 5);
+        }
+    }
+
+    private void seedSessions() {
+        Member member = memberRepository.saveAndFlush(Member.builder()
+                .email("resend-deadlock@test.com").username("재전송데드락").password("dummy")
+                .role(UserRole.USER).build());
+        memberId = member.getId();
+
+        Category category = categoryRepository.findByName("LOWER")
+                .orElseGet(() -> categoryRepository.save(Category.builder().name("LOWER").build()));
+        Exercise exercise = exercisesRepository.saveAndFlush(Exercise.builder()
+                .name("스쿼트").category(category).expectedDurationMinutes(15)
+                .syncThresholdBeginner(new BigDecimal("60.00"))
+                .syncThresholdAdvanced(new BigDecimal("85.00"))
+                .build());
+
+        // 시작 시각을 같게 둔다 — created_at 이 세션 시작 시각이라 전부 같은 파티션(같은 달)에 들어간다.
+        // 동시에 운동 중인 사용자는 정의상 같은 달이므로 이것이 실사용 조건이다.
+        LocalDateTime startTime = LocalDateTime.now().withNano(0);
+        for (int i = 0; i < SESSIONS; i++) {
+            Session session = sessionRepository.saveAndFlush(Session.builder()
+                    .member(member).exercise(exercise).startTime(startTime)
+                    .status(Status.IN_PROGRESS).totalReps(0).difficultyLevel(1).build());
+            sessionIds.add(session.getId());
+        }
+    }
+
+    private List<PoseDataRequest> frames() {
+        List<PoseDataRequest> frames = new ArrayList<>();
+        for (int i = 0; i < FRAME_COUNT; i++) {
+            frames.add(PoseDataRequest.newBuilder()
+                    .setTimestampSec(i * 0.1)
+                    .setJointCoordinates("{}")
+                    .setSyncRate(72.5)
+                    .setRepNumber(1)
+                    .setSmoothedKneeAngle(120.0)
+                    .setFeedbackMessage("ok")
+                    .build());
+        }
+        return frames;
+    }
+}

docs/18-testing-guide.md

@@ -60,7 +60,8 @@ Windows PowerShell:
 | Docker 없을 때 | — | `@Testcontainers(disabledWithoutDocker = true)` → **건너뜀**. 강제로 끄려면 `-Dmysql.container=false` |
 
 쓰는 클래스: `FlywayMigrationValidationTest`(마이그레이션↔엔티티 정합 — 이 프로파일이 존재하는 첫 번째 이유),
-`PoseDataOrphanRaceTest`(FK 없는 파티션 표), `SignupUsernameRaceTest`(벤더 제약명), `WeeklySummaryBLayerRaceTest`(`JSON_TABLE`).
+`PoseDataOrphanRaceTest`(FK 없는 파티션 표), `SignupUsernameRaceTest`(벤더 제약명), `WeeklySummaryBLayerRaceTest`(`JSON_TABLE`),
+`PoseDataResendDeadlockRaceTest`(InnoDB 잠금 — 재전송 데드락 #276, 격리수준 RC 의 회귀 가드).
 `PoseDataOrphanWindowTest` 는 같은 프로파일이지만 **측정 장치**라 `-Dmeasure.orphan.window=true` 로만 돈다(4분+, 2026-09-11 에는
 30스레드 구간이 InnoDB 데드락으로 끝났다 — 미검증, 박스가 다른 컨테이너와 동거 중이었다). 새 테스트가 «H2 로는 원리상 안 된다» 면 `MySqlContainerSupport` 를
 상속하고 `@ActiveProfiles("race")` 를 붙인다 — 그 외에는 기본 프로파일에 둔다(컨테이너 기동 비용).

docs/architecture/ai-backend-changelog.md

@@ -334,6 +334,12 @@
 - **바꾼 것.** `AbstractOutboxPublisher.dispatchOne` 이 예외의 출처를 가른다 — `dispatch()` 예외 = RETRY(재시도 기록 + 백오프, 상한 초과 시 `onGivenUp` → `FAILED`), 결과 기록 단계 예외 = 예전대로 회수 대기. 예외 뒤 재시도 기록마저 실패하면 후자로 떨어져 행을 잃지 않는다.
 - **결합면 영향.** `StopAnalysis`·`ReattachAnalysis` 경로는 gRPC 실패를 이미 RETRY 로 분류해 돌려주므로(예외를 안 던지는 계약) 보통 경로는 그대로다. 달라지는 건 그 분류 밖에서 새는 예외(DB 조회 실패·gRPC 밖 런타임 예외)뿐이다 — 이제 재시도 상한을 소진한다. 갱신 트리거 2번(전달 보장)·4번(실패 처리).
 
+### #276 — fix(pose): `savePoseDataBatch` 를 READ COMMITTED 로 (2026-09-24) ⭐ 실패 처리 변경, Spring 단독
+
+- **무엇이 문제였나.** AI 재전송(`spring_client.py`, 실패 시 3회)이 원본과 겹치면 RR 에서 중복 키 한 건이 `pose_data` 의 파티션 끝(`PRIMARY` supremum)에 X 락을 잡아, 서로 다른 세션의 재전송이 동시에 겹칠 때 데드락이 됐다(동시 부하 45.9%). 지금까지는 Spring 쪽 데드락 재시도(상한 5)가 가렸고, 그 소진분은 `INTERNAL` → AI 재전송으로 되돌아가는 **두 겹** 구조였다.
+- **바꾼 것.** 이 트랜잭션만 RC — supremum 락이 안 생긴다(0/960, [`loadtest/results/r276-lock-trace-2026-09-24/`](../../loadtest/results/r276-lock-trace-2026-09-24/README.md)). 데드락 재시도는 그물로 남긴다. 분기: [`../decisions/r276-lock-root-cause-fix.md`](../decisions/r276-lock-root-cause-fix.md)
+- **결합면 영향.** RPC·proto·응답 계약은 그대로다. 달라지는 것은 «재전송이 `INTERNAL` 을 받을 확률» — 측정한 모양(다세션 중복, 워커 8)에서는 데드락이 0 이었다 — 다른 동시성·다른 삽입 모양에서의 0 은 안 쟀다. 갱신 트리거 4번(실패 처리). AI 코드 변경 없음.
+
 ---
 
 ## 5. 결합 요소별 변경 시점