[3차 과제] API별 쿼리 개수 및 트랜잭션 범위 점검

[gahyuun]

소셜 로그인

SELECT 2개

동네 인증하기

SELECT 2개

INSERT 1개

온보딩

SELECT 2개

INSERT 1개

위치 기반 법정동 조회

쿼리 개수 0

위치 기반 장소 추천

SELECT 4개

장소 상세정보 조회

SELECT 4개

장소 메뉴 조회

SELECT 2개

최근 길 안내 장소 저장

SELECT 3개

INSERT 1개

추천 검색어 조회

SELECT 3개

리뷰 업로드

SELECT 3개

INSERT 3개

장소 검색

SELECT 4개

리뷰 작성 시 위치 인증

SELECT 2개

도토리 개수 조회

SELECT - 1개

트랜잭션 범위 점검

현재 우리의 구조

• 테이블 간 물리적 FK 관계를 맺지 않고 필요 시 각 테이블의 PK 값만 필드로 들고 있음.

• 때문에 지연 로딩 등을 걱정할 필요가 없으므로, OSIV 설정을 Off함.

  • 메서드 단위로 @Transactional 사용 (조회의 경우 readOnly = true 사용)

• 일반적으로 Spring에선 메서드 호출 시점부터 종료 시점까지를 하나의 트랜잭션으로 묶어줌, 해당 메서드가 시작될 때 DB Connection이 열리고, 메서드가 종료될 때 커밋/롤백이 이뤄지는 형태.

• OSIV를 끄면 요청이 들어와서 컨트롤러까지 객체를 전달할 때, 트랜잭션 스코프 범위까지만 영속성 컨텍스트가 활성화되고, 트랜잭션이 끝나는 즉시 세션이 닫힘.

  • 서비스 계층 내에서 필요한 엔티티를 모두 조회(로딩)하고 DTO 변환까지 마친 뒤 컨트롤러에 넘겨야 함.

장점

• 메서드 단위로 명확하게 분리 (유지보수에 용이)
• 서로 다른 로직을 트랜잭션 범위로 분리 → 특정 로직 실패가 다른 로직에 전이될 위험 감소 (롤백 영향 최소화)
• readOnly = true로 더티 체킹을 최소화하여 약간의 성능상 이점을 가짐.
• N+1 문제로부터 자유로워짐.

단점

• 트랜잭션 세분화로 인해 오버헤드가 증가할 수 있음 (자주 열고 닫는 구조라면)
• 필요 이상으로 많은 DB 쿼리 호출 가능성 (지연 로딩 등을 미사용)
• 설계 시 많은 공수가 듦, 잘못 설계할 시 중복 쿼리가 발생하거나 중간 데이터가 불일치할 위험성이 있음. (Over Fetch나 중복 조회 문제)