Shoot for the moon!

OSIV Hibernate에서는 Open Session In View라 하고, JPA에서는 Open EntityManager In View라 합니다. 관례상 OSIV이라 칭합니다. Session 쿠키, 세션 할 때 그 세션인가요? 아닙니다. DB에 접근할 수 있는 세션입니다. application.yml spring: jpa: open-in-view: true #default open-in-view: true 영속성 컨텍스트가 트랜잭션 범위를 넘어선 레이어까지 살아있습니다. API라면 클라이언트에게 응답될 때까지 View라면 랜더링 될 때까지 영속성 컨텍스트가 살아있습니다. open-in-view: false 트랜잭션을 종료할 때 영속성 컨텍스트가 닫히므로 Lazy loading 또한 할 수 없습니다. ..

앞의 예제에서는 toOne(OneToOne, ManyToOne) 관계만 있었습니다. 이번에는 컬렉션인 일대다 관계(OneToMany)를 조회하고, 최적화하는 방법을 알아보는 시간을 가져보겠습니다. 요구사항 "주문내역에서 추가로 주문한 상품 정보를 추가로 조회하자." 그럼 Order 기준으로 컬렉션인 OrderItem와 Item 이 필요합니다. "엔티티 직접 노출"은 이전 시간에 공부했던 것처럼 많은 문제가 있으므로, 컬렉션 조회 최적화에서는 엔티티를 DTO로 변환 한 후 최적화하는 것에 초점을 맞추도록 하겠습니다. V2 : 엔티티를 DTO로 변환(fetch join 사용 X) V3 : 엔티티를 DTO로 변환(fetch join 사용 O) 주문 조회 V2: 엔티티를 DTO로 변환(fetch join 사용 ..

간단한 주문 조회 V4: JPA에서 DTO로 바로 조회 쿼리 1번 호출 select 절에서 원하는 데이터만 선택해서 조회 V3까지는 엔티티 조회 후 DTO로 변환하는 작업을 했습니다. V4에서는 JPA에서 DTO로 바로 조회하면서 조금 더 성능 최적화를 해보겠습니다. ❗의존관계 Repository에서 Controller 쪽으로 의존관계가 생기면 망합니다. 의존관계는 한 방향으로 해야합니다. Controller → Service → Repository로 가야 합니다. OrderSimpleApiController @GetMapping("/api/v4/simple-orders") public List ordersV4() { return orderRepository.findOrderDtos(); } OrderS..

간단한 주문 조회 V3: 엔티티를 DTO로 변환 (fetch join 사용 O) 결론 : fetch join으로 쿼리 1번 호출 V2에서 발생한 성능 문제(N+1)를 해결하기 위해서 페치 조인을 사용해보겠습니다. ❗ [중요] ❗ 실무에서 JPA 성능 문제의 90%는 N+1에서 발생하고 페치 조인은 성능 최적화를 위해서 자주 사용하기때문에 100% 이해하고 있어야 합니다. OrderSimpleApiController package jpabook.jpashop.api; /** * @XToOne 관계(ManyToOne, OneToOne에서의 성능최적화) * Order * Order -> Member * Order -> Delivery */ @RestController @RequiredArgsConstructo..

간단한 주문 조회 V2: 엔티티를 DTO로 변환 (fetch join 사용 X) 결론 : 지연 로딩으로 쿼리 N번 호출 N + 1문제 해결 : fetch join 사용 → V3에서 설명 OrderSimpleApiController package jpabook.jpashop.api; /** * @XToOne 관계(ManyToOne, OneToOne에서의 성능최적화) * Order * Order -> Member * Order -> Delivery */ @RestController @RequiredArgsConstructor public class OrderSimpleApiController { private final OrderRepository orderRepository; @GetMapping("/ap..

앞으로 4개의 포스팅에 걸쳐서 지연 로딩 때문에 발생하는 성능 문제를 단계적으로 해결해보겠습니다. 오늘은 첫 번째 시간으로 V1(버전 1)에 대해서 정리하고 문제점과 주의점 그리고 대안에 대해서 정리해보겠습니다. 추천드리는 방법은 아니기 때문에 가볍게 보시면 될 것 같습니다. 결론 : 엔티티를 직접 노출하지 말자! 간단한 주문 조회 V1 : 엔티티를 직접 노출 주문(Order) + 배송정보(Delivery) + 회원(Member)을 조회하는 API를 만들어보겠습니다. OrderSimpleApiController package jpabook.jpashop.api; import jpabook.jpashop.domain.Order; import jpabook.jpashop.repository.OrderRepo..

영속성 전이에 대해 많은 오해들이 있습니다. 연관관계 매핑이나 즉시, 지연 로딩과 어떠한 관계가 있을 것이라고 생각하는데요. 이번 시간에 영속성 전이에 대해 알아보면서 왜 쓰이고 언제 쓰이는지 그리고 주의점은 어떤 게 있는지 정리해보겠습니다. 영속성 전이 언제 쓰이는가? 특정 Entity를 영속 상태로 만들 때, 연관된 Entity도 함께 영속 상태로 만들고 싶을 때 사용합니다. 예) 부모 Entity 저장 시 연관된 자식 Entity도 함께 저장할 때 쓰임 코드로 이해해 보겠습니다. @Entity @Getter @Setter public class Parent { @Id @GeneratedValue private Long id; private String name; @OneToMany(mappedBy ..

프록시 포스팅에 이어서 즉시 로딩과 지연 로딩의 주제로 넘어가 보겠습니다. 지연 로딩 LAZY를 사용해 프록시로 조회 @Entity public class Member{ ... @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "TEAM_ID") private Team team; ... } member 조회 시 (team을 Join하지 않고) member만 조회 쿼리 나가고 team 객체는 Proxy 객체로 생성됨. 이후실제로 team을 사용하는 시점에 초기화(DB 조회) 되면서 쿼리 나감 만약 Member와 Team을 자주 함께 사용한다면, 즉시 로딩 EAGER를 사용해 함께 조회 @Entity public class Member { ... @ManyToO..

프록시는 그 자체의 개념뿐만 아니라 즉시 로딩, 지연 로딩을 온전히 이해하기 위해 알아두어야 하는 개념입니다. 프록시를 왜 써야 하는지부터 차근차근 알아보도록 하겠습니다. 프록시를 왜 써야 하는가? Member를 조회할 때 Team도 함께 DB에서 조회해야 할까? Team을 사용하지 않는 경우 = Team까지 조회를 하는 것은 리소스의 손해이다 해결 : 프록시를 써서 지연로딩을 이용하면, 실제 필요할 때 Team을 DB에서 조회하여 리소스를 절약할 수 있다. 프록시 em.find() vs em.getReference() em.find(): 데이터베이스를 통해서 실제 엔티티 객체 조회 em.getReference(): 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회 DB에 쿼리가 안 나가는데 객..

[API 개발 고급] 시리즈 소개 현업에서 실제 발생하는 문제를 통해 어떻게 하면 API 성능최적화를 할 수 있는지 알아보는 시간입니다. 보통 성능문제는 등록과 수정이 아닌 "조회"에서 발생하므로 조회할 때 문제상황을 제시하고 해결해보겠습니다. JPA N+1문제도 같이 해결해보겠습니다. 본격적으로 들어가기전 샘플 데이터를 입력해보겠습니다. 최종적으로 주문2건이 만들어집니다. userA JPA1 BOOK JPA2 BOOK userB SPRING1 BOOK SPRING2 BOOK @Component - 스프링 빈 등록 참고 : https://cbw1030.tistory.com/54 @PostConstruct - 객체의 초기화 부분 - 객체가 생성된 후 별도의 초기화 작업을 위해 실행하는 메소드를 선언한다. ..