[JPA] 프록시와 연관관계

프록시

Member가 Team을 참조하고 있다면, Member를 조회할 때 Team도 참조해야 하는가?

회원만 필요한 경우도 있고 팀도 필요한 경우가 존재하는데 최적화는?

 

프록시 기초

1. em.find() vs em.getReference()

2. em.find(): 데이터베이스를 통해서 실제 엔티티 객체 조회

3. em.getReference(): 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회

프록시 특징

1. 실제 클래스를 상속 받아서 만들어진다.

2. 실제 클래스와 겉 모양이 같다.

3. 사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 된다. (이론상)

4. 프록시 객체는 실제 객체의 참조(target)를 보관한다. 

5. 프록시 객체를 호출하면 프록시는 실제 객체의 메소드를 호출한다.

프록시 객체의 초기화

프록시의 특징

1. 프록시 객체는 처음 사용할 때 한번만 초기화

2. 프록시 객체를 초기화할 때, 프록시 객체가 실제 엔티티로 바뀌는 것이 아니라,

초기화되면 프록시 객체를 통해 실제 엔티티 객체로 접근한다.

3. 프록시 객체는 원본 엔티티를 상속받은 객체이다. (== 말고 instanceof 사용)

4. 영속성 컨텍스트는 찾는 엔티티가 이미 있으면, em.getReference()를 호출해도 실제 엔티티를 반환한다.

(== 연산에 맞도록)

5. 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일때, 프록시를 초기화하면 문제 발생.

(데이터가 영속되지 않았는데, 데이터를 조회하려고 하는 경우)

 

즉시 로딩과 지연

 

프록시와 즉시로딩 주의

1. 가급적 지연 로딩만 사용(특히 실무에서) 

2. 즉시 로딩을 적용하면 예상하지 못한 SQL이 발생할 수 있다.

 

3. 즉시 로딩은 JPQL에서 N+1 문제를 일으킨다.

JPQL로 멤버 리스트를 조회했다. (1번), 이후에 즉시 로딩을 통해 참조된 Team을 조회한다면? (N번)

 

4. @ManyToOne, @OneToOne은 기본이 즉시 로딩으로 되어 있다. (~ToOne)

=> LAZY로 변경한다. 

 

지연 로딩 활용(이론적)

1. Member와 Team은 자주 함께 사용됨 => 즉시로딩

2. member와 Order는 가끔 사용 => 지연 로딩

3. Order와 Product는 자주 함께 사용 => 즉시 로딩

 

지연 로딩 활용(실무)

1. 모든 연관관계에서 지연 로딩을 사용하자. 

2. 실무에서 즉시 로딩 사용하지 말자.

3. 즉시 로딩은 N+1 문제를 만든다. 

 

영속성 전이 CASCADE

1. 특정 엔티티를 영속 상태로 만들 때, 연관된 엔티티도 함께 영속하고 싶은 경우

2. 예) 부모 엔티티를 저장할 때, 자식 엔티티도 함께 저장

3. 영속성 전이는 영관관계를 매핑하는 것과 관련이 없다. 단순 편리성 제공 

CASCADE의 종류

1. ALL: 모두 적용

2. PERSIST: 영속

3. REMOVE: 삭제

4. MERGE, REFERSH, DETACH...

 

고아객체

1. 고아객체 제거: 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제

2. orphanRemoval = true

3. 참조하는 곳이 하나 일 때 사용한다. 

4. @OneToOne, @OneToMany만 사용 가능

 

영속성 전이 + 고아객체, 생명주기

1. CascadeType.ALL + orphanRemoval = true

2. 스스로 생명주기를 관리하는 엔티티는 em.persist로 영속화 em.remove로 제거

3. 두 옵션을 모두 활성화 하여 부모 엔티티로 자식의 생명주기를 관리할 수 있다. 

 

출처: 자바 ORM 표준 JPA 프로그래밍(김영한)