뽀루피의 개발스토리

xToOne Fetch Join우리가 기존에 알고있던 Fetch Join이다.  xToMany Fetch JoinxToOne 패치 조인과 다르게 부작용이 생긴다.1. 페이징이 불가능하다. 만약 페이징을 설정하게 되면 모든 데이터를 DB에서 읽어오고 메모리에서 별도로 페이징을 해버린다. 이렇게되면 OutOfMemory 오류가 터질 수 있다. 위험하므로 사용하지 말아야한다. 페이징은 성능에 뛰어난 성능을 보이고 현업에서 많이 사용하므로 xToMany 관계에서는 패치 조인을 쓰면 안되겠다.(페이징이 불가한 이유는 ToMany 관계는 조회 row 수를 늘리기 때문이다. 조회한 데이터에 같은 id의 데이터 수가 많으면 페이징하기 곤란하기 때문이다.) 2. 컬렉션 패치 조인은 1개만 사용할 수 있다. 2개 이상부터..

OpenSessionInView (기본값 true)JPA에서는 EntityManager로 DB 커넥션을 유지하지만 JPA의 전신인 Hibernate에서는 Session으로 유지하기에 이름이 이렇게 붙었다.  True true인 경우, 최초의 DB 커넥션 시작 시점부터 API 응답이 끝날 때까지 영속성 컨텍스트와 DB 커넥션을 유지한다. 그래서 OSIV 설정을 따로 변경안했을 때 View Template이나 Controller에서 지연로딩이 가능했던 것이다(1차 캐시 유지). 하지만 현업에서는 이를 False로 막아놓는다. 이유가 뭘까? 그 이유는 API에 블록킹이나 연결이 길어지는 이슈가 생긴다면 DB 커넥션 리소스가 말라버리기 때문이다. 실시간 트래픽이 중요한 애플리케이션에서는 커넥션 리소스가 부족해질..

Fetch Join은 N+1문제를 해결하고 성능을 향상시킬 수 있는 기능이다. 오늘은 어떻게 Fetch Join이 성능을 향상시키는지 알아보자. 우선 Fetch Join에 대해서 정리하고 가야할 것이 있는데 Fetch Join은 DB에서 지원하는 기능이 아닌 JPA의 JPQL에서 제공하는 기능이다. 그렇다면 Join에서 어떤 것이 부족해서 Fetch Join이라는 함수를 따로 만들었을까? 이는 객체와 테이블을 맵핑하려는 데에서 파생된 문제에서 시작되었다. 아래와 같은 Member와 Team이라는 테이블이 있다고 하자.  Member는 Team과 다대일의 관계를 가지고 있다. 만약 Member 전체를 조회하는 JPQL을 짠다면 Team의 ID, 이름, 나이가 영속성 컨텍스트에 저장되고 Team 엔티티는 조..