Spring/JPA

현재 진행하고 있는 프로젝트의 메인 페이지를 페이징 기능을 사용해서 구현했다. 모바일 환경에 최적화해서 개발했기 때문에 Offset과 Limit을 사용한 게시판 형식의 기본 페이징이 아닌, 무한 스크롤 방식을 사용하기로 결정 했다. 아래에 보이는 망고플레이트의 페이징 기능을 구현했다고 보면 된다. 제목에서 설명한대로 무한 스크롤을 구현하기 위해서 No Offset 방식과 Slice를 사용했는데, 두 가지 방식이 무엇이고, 왜 사용해야 하는지 알아보자. No Offset 방식은 무엇이고 왜 사용하는가 기존의 페이징은 offset과 limit을 사용해서 페이징할 범위를 정한다. 이 방식은 초반에는 효율이 나쁘지 않지만 뒤로 갈수록 효율이 급격히 떨어진다는 단점이 있다. 왜 이런 현상이 발생하는지 알아보자. ..

문제 JPA를 사용하면서 서로 다른 엔티티를 save할때 id값이 엔티티 별로 나누어지지 않고 합쳐서 올라가는 경험을 한 적이 있을 것이다. commentRepository.save(new Comment()); memberRepository.save(new Member()); 예를 들어 위의 코드를 실행하면 이렇게 엔티티별로 id가 분리되지 않고 함께 증가하는걸 알 수 있다. @GeneratedValue를 사용하면 default값으로 AUTO가 적용되고, AUTO는 IDENTITY를 기본으로 사용한다고 알고 있었는데, 실제로 적용되는 전략은 IDENTITY가 아니였던 것이다. 실제 어떤 전략이 적용되었는지 확인해보면, 사진에서 볼 수 있듯이 테이블 시퀸스가 적용된것을 알 수 있다. 테이블 시퀸스 전략이란..

기본적으로 트랜젝션과 영속성 컨텍스트는 범위를 같게 한다. 순서는 → 스프링 트랜젝션 AOP 동작 → 트랜젝션 내 메서드 호출 → 트랜젝션 커밋 직전 영속성 컨텍스트 플러시 → 트랜젝션 종료 → 그 이후 엔티티는 준영속 상태 여러 쓰레드가 하나의 엔티티 매니져에 접근 할 수 있지만, 쓰레드마다 트랜젝션이 별개로 할당되기 때문에 영속성 컨텍스트도 따로 할당된다. 근데 이 상태에서는 변경 감지나 지연로딩을 사용하지 못한다. 이것들은 모두 영속성 컨텍스트가 살아있을때만 가능하다. 지연로딩은 트랜젝션과 상관없이 영속성 컨텍스트만 살아있으면 된다. 지연로딩은 즉시로딩의 N+1 문제를 해결해준다. 하지만 지연로딩 자체도 DTO로 변환할때 N+1문제를 가질 수 있다. 즉시로딩에서의 N+1 문제 과정 -> JPQL은 ..

JPA에서 영속성 컨텍스트는 가장 중요한 내부 동작 원리 중 하나입니다. 오늘은 영속성 컨텍스트의 역할과 구성에 대해서 정리해보겠습니다. 영속성 컨텍스트란 우선 영속성 컨텍스트는 눈에 보이지 않는 논리적인 개념입니다. 우리는 엔티티 매니저를 통해서 이 논리적인 공간에 접근 할 수 있습니다. # 먼저 엔티티 매니져를 생산할 수 있는 엔티티 팩토리를 만들어줍니다. EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello"); EntityManager em = emf.createEntityManager(); # persist를 통해서 entity를 영속성 컨텍스트에 저장할 수 있다. em.persist(entity); 위 코드의 pers..