일대다 Join (Collection Join) 일대다 연관관계를 가지는 엔티티들이 있다고 가정해보자. 이 때, 'One'을 기준으로 "Many"를 Join하는 경우를 생각해보자. One은 말 그대로 하나다. Many는 말 그대로 여러개다. 따라서 One + Many를 Join할 경우, 각 엔티티의 Row 갯수가 맞지 않는다. DB는 이 때, Many의 Row 수를 기준으로 One의 Row를 맞춘다. List findMember = queryFactory.selectFrom(member) .join(member.orderList, order) .fetch(); 예를 들어 위처럼 일대다 쿼리를 보낸다고 해보자. 그렇다면 DB 단의 테이블은 어떻게 만들어질까? DB 테이블은 member와 order를 Ord..
JPA 일대다 연관관계 → DB 반영은? JPA 일대다 연관관계에서 DB 반영은 어떻게 일어날까? '일대다' 연관관계의 의미처럼 '일'은 테이블에 1개만 저장된다. '다'는 테이블에 여러개가 저장된다. 즉, '일'의 PK를 FK로 가지는 여러 개의 '다'가 만들어지고 각각 저장된다. 아래 예시를 통해 확인해본다. Member Entity @Entity @Data @ToString(of = "name") public class Member { @Id @GeneratedValue @Column(name = "member_id") private Long id; private String name; @OneToMany(mappedBy = "member", cascade = CascadeType.ALL, fetc..
이 게시글은 자바 ORM 표준 JPA 프로그래밍 책을 보고 공부한 내용을 정리한 글입니다. 영속성 컨텍스트와 1차 캐시 영속성 컨텍스트는 내부적으로 1차 캐시를 가지고 있다. 이 1차 캐시는 DB에서 가져온 엔티티를 영속화 해두는 저장소 역할을 한다. 이 저장소는 스냅샷을 만들어 더티 체킹도 하지만, PK 값으로 엔티티를 관리하기 때문에 엔티티의 비교에도 아주 유용한 기능을 제공한다. 영속성 컨텍스트가 1개 일 때, 엔티티 비교. 영속성 컨텍스트가 1개일 때 엔티티를 비교하면 어떻게 될까? OSIV 환경을 가정하고 비교해보자. 먼저 빈 영속성 컨텍스트에 PK가 1인 엔티티를 DB에서 영속화했다. 그럼 영속성 컨텍스트의 1차 캐시에 이 엔티티는 영속화된다. 그리고 이 엔티티를 A라는 변수에 참조하도록 한다..
이 게시글은 자바 ORM 표준 JPA 프로그래밍을 보고 필요한 부분을 정리한 글입니다. 스프링의 영속성 컨텍스트 기본전략 스프링의 영속성 컨텍스트 기본 전략은 트랜잭션을 시작할 때, 영속성 컨텍스트를 만든다. 그리고 트랜잭션이 끝날 때 영속성 컨텍스트를 종료하는 것이다. 따라서 트랜잭션과 영속성 컨텍스트의 생명주기는 동일하다. 스프링에서는 같은 트랜잭션 내에서는 어떤 위치에서 엔티티 매니저를 주입 받더라도 같은 영속성 컨텍스트를 관리하는 것이 보장된다. 항상 같은 엔티티 매니저가 주입되지 않을 수 있다. 그렇지만 서로 다른 엔티티 매니저가 들어오더라도 동일 트랜잭션에서는 동일 영속성 컨텍스트만을 관리하게 된다. 스프링은 쓰레드마다 서로 다른 영속성 컨텍스트를 배정한다. 따라서 멀티 쓰레드 환경에서 서로 ..
이 글은 자바 표준 ORM JPA를 읽고 정리한 글입니다. JPA 쿼리 성능 최적화 JPA는 읽기 전용 쿼리를 생성해서 조회 시, 쿼리를 좀 더 최적화 할 수 있다. 이 때의 가장 주된 효과는 1) 스냅샷을 만들지 않게 하거나 2) Flush()를 하지 않게 하면서 성능 최적화를 이끌어 낸다. 읽기전용 엔티티로 성능 최적화 1. 스칼라 타입으로 값을 불러온다. 스칼라 타입으로 엔티티를 불러오면 이 엔티티는 영속성 컨텍스트에서 관리하지 않는다. 따라서 스냅샷도 만들어지지 않고, 더티 체킹 등의 무거운 로직도 스킵된다. 2. 쿼리 힌트를 준다. 스프링 데이터 JPA에서는 @Query에 힌트를 줄 수 있고, 순수 JPA에서는 query.sethint로 읽기 전용 힌트를 줄 수 있다. ReadOnly 힌트를 주..