JPA 프록시와 연관관계 관리

프록시

프록시 기초

- em.find() vs em.getReference()

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

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

 

프록시 특징

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

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

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

 

- 프록세 객체는 실제 객체의 참조(target)을 보관

- 프록시 객체를 호출하면 프록시 개체는 실제 객체의 메소드 호출

 

프록시 객체의 초기화

Member member = em.getReference(Member.class, member.getId());
member.getName(); // 이 때 프록시에 대한 쿼리가 나감

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

- 프록시 객체를 초기화할 때, 프록시 객체가 실제 엔티티로 바뀌는 것은 아님, 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근 가능

- 프록시 객체는 원본 엔티티를 상속받음, 따라서 타입 체크 시 주의해야 함 (== 비교 말고 instance of 사용)

- 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해도 실제 엔티티 반환 (반대로도 마찬가지 프록시 반환)

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

 

프록시 확인

- 프록시 인스턴스의 초기화 여부 확인 emf.getPersistenceUnitUtil().isLoaded()

- 프록시 클래스 확인 방법 em.getClass().getName()

- 프록시 강제 초기화 Hibernate.initialize(entity)

 

즉시 로딩과 지연 로딩

Member를 조회할 때 Team도 함께 조회해야 할까?

 

지연 로딩

지연 로딩 LAZY를 사용해서 프록시로 조회

@ManyToOne(fetch = FetchType.LAZY)

즉시 로딩 EAGER를 사용해서 함께 조회

@ManyToOne(fetch = FetchType.EAGER)

프록시와 즉시로딩 주의

- 가급적 실무에서는 지연 로딩만 사용

- 즉시 로딩은 예상하지 못한 SQL 문제 발생

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

- @ManyToOne, @OneToOne은 default가 즉시 로딩 -> LAZY로 설정

- @OneToMany, @ManyToMany는 default가 지연 로딩

 

두 개의 엔티티를 조회할 수 밖에 없을 때에는?

즉시 로딩 말고 fetch join, 엔티티 그래프 탐색 등을 사용하여 해결하면 된다.

 

지연 로딩(LAZY Loading) 활용 - 실무

- 모든 연관관계에 지연 로딩을 사용해라!

- 실무에서 즉시 로딩을 사용하지 마라!

 

영속성 전이: CASCADE

- 특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때

- 부모 엔티티 저장하면 자식 엔티티도 함께 저장

 

@OneToMany(cascade = CascadeType.persist)

 

영속성 전이: CASCADE - 주의

- 영속성 전이는 연관관계를 매핑하는 것과 아무 관련이 없음

- 엔티티를 영속화할 때 연관된 엔티티도 함께 영속화하는 편리함을 제공

 

CASCADE의 종류

- ALL

- PERSIST

- REMOVE

- MERGE

- REFRESH

- DETACH

 

고아 객체

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

- orphanRemoval = true

 

고아 객체 - 주의

- 참조하는 곳이 하나일 때 사용해야한다!

- 특정 엔티티가 개인 소유할 때 사용

 

 

출처 : 자바 ORM 표준 프로그래밍