3-3. 간단주문조회V3 : 페치조인 최적화

JPA책 p.585 중.

# 현재 문제 : 트랜젝션은 service 계층에서 닫히므로 영속성컨텍스트에서도 닫힌다. -> 프레젠테이션 계층에서의 엔티티는 준영속상태이다. -> 의존하는 다른 객체에 접근 시 DB로 부터 로딩해 오지 못하기 때문에 LazyInitializationException 발생.

 

# 해결법 3가지

프레젠테이션계층에 필요한 엔티티를 미리 로딩해두는 방법은 어디서 미리 로딩하느냐에 따라 3가지 방법이 있다.

1. 글로벌 페치 전략 수정 (LAZY -> EAGER)

2. JPQL 페치 조인 ( JPQL을 호출하는 시점에 함께 로딩할 엔티티를 선택할 수 있음.)

3. 강제로 초기화

 

(여기서 프레젠테이션계층에 필요한 엔티티라 함은. 엔티티를 DTO로 변환하는 과정에서 엔티티(아직 프록시 객체) 에 접근해야하기 때문에 이렇게 표현했다. )

 

 

# 각각 방법의 단점

1. - 사용하지 않는 엔티티를 로딩한다. (API마다 각각의 응답값이 다르다.)

    - N+1 문제가 발생한다.

2. 

 

 

 

 

====== 강의 . fetch join

 

지금 V2의 문제 : 쿼리가 너무 많이 나간다. 

 

여기서 N+1 발생하는건 2,5번째 줄이므로 member, delivery를 fetch join 한다.

 

OrderRepository

페치 조인 사용.

Order 조회 시 SQL 입장에서는 join 이면서 SELECT절에서 한번에 가져옴.

(Member, Delivery 가 LAZY 상태 이지만 페치 조인 시 무시하고 실제 객체 값 을 가져옴.(프록시 아님))

 

=> 결론 = 페치 조인 : join해서 한번의 SELECT에 가져오게 함.

 

 

N + 1 의 90%는 페치조인으로 해결가능 

(기본으로 LAZY로 깔고 필요한것만 join으로 객체그래프로 묶어서 한번의 SELECT로 가져온다!!!!!)

(기본으로 LAZY로 깔고 필요한것만 join으로 객체그래프로 묶어서 한번의 SELECT로 가져온다!!!!!)

(기본으로 LAZY로 깔고 필요한것만 join으로 객체그래프로 묶어서 한번의 SELECT로 가져온다!!!!!)

(기본으로 LAZY로 깔고 필요한것만 join으로 객체그래프로 묶어서 한번의 SELECT로 가져온다!!!!!)

(기본으로 LAZY로 깔고 필요한것만 join으로 객체그래프로 묶어서 한번의 SELECT로 가져온다!!!!!)

(기본으로 LAZY로 깔고 필요한것만 join으로 객체그래프로 묶어서 한번의 SELECT로 가져온다!!!!!)

 

=> 대부분 성능 문제 해결.

 

 

V3 개발완료

V2와 결과는 동일하다.

 

하지만 V2는 쿼리가 5번 나가지만 페치조인을 쓴 V3은 1번 나간다...(페치조인 붙은 칼럼을 SQL에서 join해서 SELECT 한 번으로 다 끌고와서 가져온다.)

 

SQL로 한땀한땀 짜려면 한 세월이다 -> JPA로 쉽게 짰다.

 

 

 

결론 : 페치조인은 적극적으로 활용하자! 좋은 성능!

실무에서도 자주씀