kdh93

Open Session in View : JPA에서 영속성 컨텍스트의 생존 범위를 어디까지 설정할지 처리하는 패턴. 따로 설정해놓지않으면 기본값은 true로 되어있다. true인 경우 Open Session in view 이름 그대로 Spring에서 View를 반환할때 까지 영속성 컨텍스트가 생존한다. 컨트롤러 계층에서 지연로딩 초기화가 가능하단 이야기. 이 경우의 장점은 앞서 말한 영속성 컨텍스트의 생존 범위가 대략 인터셉터부터 리파지토리까지 요청을 받고 응답을 보낼때까지 살아있기때문에 코드 작성이 수월해진다. 어느 계층에서던 Entity를 조회하거나 초기화 할 수 있다. 단점으로 그만큼 요청이 처리되는 긴 시간동안 데이터베이스 커넥션을 계속 가지고있기에 웹 어플리케이션 성능에 문제가 생길 수 있다. ..

어제 공부하면서 배운 ~~toOne 관계는 Collection이 아닌 객체 한개를 조회하기때문에 fetch Join을 사용하면 큰 문제는 없었다. 이번 강의에서는 ~~toMany 관계가 포함된 Order 를 조회하면서 문제점과 해결방안에대해 알아봤다. 우선 toOne관계와 똑같이 fetch Join이 들어간 방식이 DB에 쿼리를 어떻게 전송하는지와 응답한 JSON을 살펴보자. 기존 처럼 fetch join을 이용해 get요청을 했더니 첫번째 문제가 발생했다. JSON에 중복된 데이터가 응답됬다. 이유가 뭘까 Hibernate가 DB에 전송한 쿼리를 H2에 날려 어떤 테이블 형식을 가지는지 봤더니 1개의 Order를 조회할때 Order가 ~~toMany 관계로 가지고있는 OrderItem 2개를 join하..

JPA 강의를 보고 복습 겸 남겨보는 JPA N+1문제와 해결방법인 FetchJoin 우선 첫번째 조회 API 방식은 fetchJoin을 사용하지않고 DTO로 변환 후 응답하는 방식 지연 로딩을 DTO Class에서 getter로 초기화하며 원하는 값들을 가져오기엔 성공했지만, 1개의 Order를 조회할때 쿼리가 한번 Lazy된 Member를 조회할때 또 쿼리가 한번 Lazy된 Delivery를 조회할때 또또 쿼리가 한번 여기서 두개의 Order를 조회한다면 DTO에서 지연로딩을 초기화 하는과정에서 또 Member와 Delivery 값을 가져오는 쿼리가 날라가 Memeber, Delivery에 관한 쿼리가 총 4개가 날라간다. 이는 성능 저하 이슈로 이어진다. 1개의 쿼리를 조회할때 + N 개의 쿼리가 ..