해당 시리즈는 김영한님의 JPA 로드맵을 따라 학습하면서 내용을 정리하는 글입니다

프록시

프록시 기초

• em.find() vs em.getReference()
• em.find(): 데이터 베이스를 통해서 실제 엔티티 객체 조회
• em.getReference(): 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 조회
  • getReference하는 시점에는 쿼리를 날리지 않다가 실제로 사용하는 시점에서 쿼리를 날려서 데이터베이스에서 가져옵니다

프록시 특징

• 실제 클래스를 상속 받아서 만들어집니다
• 실제 클래스와 겉 모양이 같습니다
• 사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 됩니다
• 프록시 객체는 실제 객체의 참조(target)를 보관합니다
• 프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드를 호출합니다

프록시 객체의 초기화

Member member = em.getReference(Member.class, "id1");
member.getName();

• getName이 호출되는 시점에 영속성 컨텍스트에 요청을 합니다
• 영속성 컨텍스트를 통해서 실제 엔티티를 프록시 객체안의 target에 실제 객체를 매핑해 줍니다

프록시의 특징

• 프록시 객체는 처음 사용할 때 한번만 초기화됩니다
• 프록시 객체를 초기화할때, 프록시 객체가 실제 엔티티로 바뀌는 것은 아님, 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근 가능해 지는 겁니다
• 프록시 객체는 원본 엔티티를 상속받습니다, 따라서 타입 체크시 주의해야 합니다 (== 비
  교 실패, 대신 instance of 사용해야 합니다)
• 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해도 실제 엔티티 반환
  • JPA에서는 같은 트랜잭션에서 타입이 같은 두 객체를 비교할 때(==) 무조건 true를 보장하기 때문에 이미 영속성 컨텍스트에 있으면 프록시 객체를 생성하지 않고 실제 엔티티를 반환합니다
• 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하면 문제가 발생합니다(하이버네이트는 org.hibernate.LazyInitializationException 예외를 터트립니다)

프록시 확인

• 프록시 인스턴스의 초기화 여부 확인
  • PersistenceUnitUtil.isLoaded(Object entity)

EntityManagerFactory emf = Persistence.createEntityManagerFactory(...);
emf.getPersistenceUnitUtil().isLoaded(entity);

• 프록시 클래스 확인 방법
  • entity.getClass().getName() 출력
• 프록시 강제 초기화
  • org.hibernate.Hibernate.initialize(entity);
• 참고: JPA 표준은 강제 초기화가 없습니다
  • 강제 호출: member.getName() 등으로 초기화 유도

즉시 로딩과 지연 로딩

객체를 조회할 때 관계된 객체도 조회해야 할까?

• 단순히 그 조회하는 해당 객체만 사용하는 비즈니스 로직인 경우
  • System.out.println(member.getName());

지연로딩 옵션 제공

@Entity
public class Member {
	...    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "TEAM_ID")
    private Team team;
    ...
}

• Team 객체는 프록시 객체로 조회하게 됩니다
• 그 이후 Team 객체를 사용하는 시점에 쿼리를 조회해서 진짜 Team의 엔티티로 교체됩니다

즉시로딩

@Entity
public class Member {
	...    
    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "TEAM_ID")
    private Team team;
    ...
}

• Member 객체를 조회해서 사용할 때 많은 경우 Team 객체를 같이 사용하는 로직이 대부분이라면 EAGER 옵션을 통해서 즉시로딩을 하는게 좋습니다(두 번의 쿼리가 안나갈 수 있기 때문입니다)

프록시와 즉시로딩 주의할 점

• 가급적이면 지연 로딩만 사용하도록 합니다(특히 실무에서는)
• 즉시 로딩을 적용하면 예상하지 못한 SQL이 발생합니다
  • 너무 많은 JOIN이 발생할 수 있습니다
• 즉시로딩은 JPQL에서 N + 1 문제를 일으킵니다

  		List<Member> members = em.createQuery("select m from Member m", Member.class)
  			.getResultList();

  • JPQL은 SQL로 번역되고 실행됩니다. 따라서 위 코드도 SQL로 번역되고 쿼리문 대로 Member만 선택하게 됩니다. 하지만 설정에 EAGER로 되어있으면 즉시로딩이기 때문에 한번 더 쿼리를 보내서 Member마다 연결된 Team의 정보까지 불러오는 겁니다. 원치않게 쿼리가 두번 실행되게 됩니다
• @ManyToOne, @OneToOne은 기본이 즉시 로딩입니다 -> LAZY로 설정해야 합니다
• @OneToMany, @ManyToMany는 기본이 지연 로딩입니다

지연로딩 활용

• 모든 연관관계에 지연 로딩을 사용하도록 합니다
• 실무에서 즉시 로딩을 쓰면 안됩니다
• JPQL fetch 조인이나, 엔티티 그래프 기능을 사용하도록 합니다
• 즉시 로딩은 상상하지 못한 쿼리가 나가므로 주의합시다

영속성 전이: CASCADE

• 특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때
  • ex) 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장
• 영속성 전이는 연관관계를 매핑하는 것과는 전혀 관련이 없습니다
• 엔티티를 영속화할 때, 연관된 엔티티도 함께 영속화하는 편리함을 제공하는 것입니다

CASCADE 종류

• ALL: 모두 적용
• PERSIST: 영속
• REMOVE: 삭제
• MERGE: 병합
• REFRESH: REFRESH
• DETACH: DETACH

고아 객체

• 고아 객체 제거: 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제합니다
• orphanRemoval = true

Parent parent1 = em.find(Parent.class, id);
parent1.getChildren().remove(0);
// 자식 엔티티를 컬렉션에서 제거

• DELETE FROM CHILD WHERE ID=?

고아 객체 주의할 점

• 참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아객체로 보고 삭제가 됩니다
• 참조하는 곳(엔티티)가 하나일 때 사용해야 합니다
• 특정 엔티티가 개인 소유할 때 사용해야 합니다
• @OneToOne, @OneToMany만 가능
• 부모 엔티티를 삭제하면, 자식 엔티티는 고아가 됩니다. 따라서 고아 객체 제거 기능을 활성화하면, 부모를 제거할 때 자식도 함께 제거됩니다. CascadeType.REMOVE 처럼 동작합니다

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

• CascadeType.ALL + orphanRemoval = true
• 스스로 생명주기를 관리하는 엔티티는 em.persist()로 영속화하고, em.remove()를 통해서 제거합니다
• 하지만 두 옵션을 모두 활성화한 자식 엔티티는 부모 엔티티를 통해서 생명주기를 관리할 수 있습니다
• 도메인 주도 설계(DDD)의 Aggregate Root 개념을 구현할 때 유용합니다