백엔드
데이터가 있었는데요, 아니 없어요
두줄요약
회원 조회가 간헐적으로 실패하던 원인을 COMMIT, MVCC, autocommit 설정 관점에서 분석했습니다. `@Transactional(readOnly = true)`와 open-in-view 영향까지 확인해 조회 흐름을 정리했습니다.
문제 상황
- Master DB에 INSERT된 회원 데이터가 같은 서비스 흐름에서 간헐적으로 조회되지 않는 현상
- 다시 요청하면 조회되는 비정상적 반복 패턴
- Master/Slave 조회, COMMIT 누락, open-in-view, readOnly 트랜잭션 설정이 얽힌 복합 이슈
원인 분석
- Replica Lag이 아니라 Master DB에서 실행된 조회가 COMMIT 없이 종료되며 오래된 Snapshot을 유지한 점
hikari.auto-commit: false와@Transactional부재로 인해 쿼리 종료 시 COMMIT 대신 ROLLBACK이 발생한 점open-in-view: true와 하위@Transactional(readOnly = true)조합으로 Snapshot 갱신이 기대와 다르게 동작한 점
해결 방법
- 조회 경로에
@Transactional(readOnly = true)를 명시해 메서드 종료 시 COMMIT이 발생하도록 조정 - 전체 조회 흐름을 Slave DB에서 일관되게 실행되도록 트랜잭션 경계 재정의
READ COMMITTED, 잠금 읽기 등 대안은 사이드 이펙트와 락 경합 가능성 때문에 제외