뽀루피의 개발스토리

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 커넥션 리소스가 말라버리기 때문이다. 실시간 트래픽이 중요한 애플리케이션에서는 커넥션 리소스가 부족해질..

auto-increment로 id를 설정해두다 보니 테스트 도중 id가 밀려 초기화를 해야할 일이 생겼다.그래서 yml 파일의 ddl-auto를 update에서 create로 바꾸고 실행시켜봤는데...일부 테이블만 초기화 되어있고 나머지는 초기화가 안되는 현상이 발생했다. 이전에 만들어두고 현재는 사용하지 않는 테이블을 삭제안하고 create 했던 것이 문제였다. 이 테이블과 연관관계를 갖는 테이블들 전부 초기화가 안되고 있던 것이다. 그래서 이 테이블을 직접 DROP하고 다시 실행해보니 오류는 말끔히 해결되었다!