JPA #8 프록시와 지연로딩 (join fetch)

📌 상황에 따라 다르다.

Member는 Team의 참조를 가지고 있다.

Member를 조회할 때 Team도 한번에 같이 데이터베이스에서 가져오는게 효율적인 경우도 있고

먼저 Member만 조회해두고, 나중에 필요할 때 Team을 가져오는게 더 효율적인 경우도 있을 것이다.

 

상황에 따라 DB 쿼리가 다르게 나가도록 최적화하는게 좋은데, 이는 JPA에서 어떻게 처리할 수 있을까?

 

 

📌 프록시 em.getReference()

그래서 JPA에서는 프록시를 제공한다.

• em.find()는 실제 엔티티를 반환한다면
• em.getReference()는 가짜 프록시 객체를 반환한다.

 

프록시는 실제 클래스를 상속받아서 만든 객체로, 실제 객체의 참조값을 가지고 있다.

사용하는 시점에 실제 객체 메서드를 호출한다. (지연호출, 위임)

프록시 객체를 사용하면 데이터의 일부만 가져올 수 있다. 가져오지 않은 데이터는 사용하는시점까지 DB쿼리를 늦춘다. 

// id 값만 조회하고, 나머진 쿼리를 날리지 않는다.
Member member = em.getReference(Member.class, member.getId());

member.getId(); // 이미 가져온 데이터 사용. DB쿼리 X

member.getName(); // 가져온적이 없는 데이터. 이 시점에 새로운 DB쿼리 발생

실제 객체를 로그로 찍어보면, Member가 아니라 Member의 프록시 객체가 반환되었음을 알 수 있다.

최초에 getReference를 호출하는 시점에는, 실제 객체의 참조를 가지고 있지않고 그냥 프록시만 만든다.

✨ 단 이미 영속성 컨텍스트에 실제 객체가 있다면 굳이 프록시를 만들지 않고 실제 엔티티를 반환한다.

그리고 실제 값이 필요할 때 영속성 컨텍스트를 통해 DB에서 조회해서 실제 객체의 참조값을 가져온다.

참고로 비영속, 준영속 상태(detach)일 때 프록시를 초기화하면 예외(hibernate.LazyInitializationException)가 발생한다.

즉, 프록시 객체는 딱 1번만 초기화되고 계속 사용된다. 중간에 실제 객체로 바뀌는게 아니다.

사용하는 시점에 DB에서 조회하고 [ 프록시 객체의 참조값 ] 에 실제 객체가 들어가는 거다.

 

✔ 프록시는 언제 사용될지 모른다. 타입비교는 instance of

엔티티의 타입 비교할 때에는 반드시 instance of를 사용해야한다.

JPA에서는 객체의 타입을 (==)로 비교해서는 안된다. 프록시랑 원본 객체를 비교하면 타입이 같아도 False가 반환된다.

 

다만 타입말고 객체의 동일성은 (==)로 비교해도 된다.

• getReference()도 이미 영속성 컨텍스트에 가져온 실제 객체가 있다면, 프록시가 아닌 실제 Entity를 반환한다.
• 동일성을 맞추기 위해서 호출 순서에 따라 em.find()도 프록시를 반환할 수도 있다.

// 실제 💶Entity가 반환됨
Member.findMember = entityManager.find(Member.class, member1.getId());

// 영속성 컨텍스트에 Entity가 있음. 프록시가 아닌 실제 💶Entity가 반환됨
Member proxyMember = entityManager.getReference(Member.class, member1.getId());

// True, 💶Entity == 💶Entity
System.out.println(porxyMember == findMember);

// ✨Proxy 객체가 반환됨
Member proxyMember = entityManager.getReference(Member.class, member1.getId());

// 실제 Entity가 반환되어야하지만, 조회해보면 ✨Proxy 객체가 반환됨
Member.findMember = entityManager.find(Member.class, member1.getId());

// True, ✨Proxy == ✨Proxy
System.out.println(porxyMember == findMember);

 

 

그래서 JPA에서는 아래와 같은 메서드를 제공해준다.

// 프록시 인스턴스의 실제 객체참조 초기화 여부 true / false
entityMangerFactory.PersistenceUnitUtil.isLoaded(Object proxyEntity)

// 클래스 이름 확인 (클래스 명으로 프록시 여부확인)
entity.getClass().getName()

사용할 일은 거의 없지만, 사용여부와 상관없이 프록시의 실제 객체 참조를 강제로 초기화하고 싶다면 아래와 같다.

org.hibernate.Hibernate.initialize(proxyEntity);

 

 

📌 다만 getReference()를 쓸 일은 거의 없다.

프록시의 동작을 이해하기위해 이런 메서드도 있다는 걸 알려준 것이다.

실제 사용은 getReference()를 쓰지않고, 애노테이션을 옵션을 통한 지연로딩을 사용한다.

 

 

📌 즉시로딩과 지연로딩

번거롭게 getRefernce()로 프록시를 관리할 필요없이, 아래와 같이하면 된다.

@Entity
public class Member {

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "TEAM_ID")
    private Team team;
}

쿼리를 찍어보면 em.find()로 조회하면 실제 객체가 아닌 프록시가 반환되었음을 알 수 있다.

즉 위에서 설명한것과 똑같이 실제 객체를 조회하는 시점 (getTeam)에서 영속성 컨텍스트에 DB쿼리가 날라가게되고, 프록시의 참조가 초기화된다.

 

반대로 Member와 Team을 항상 같이 사용해서, 한번에 모두 가져오고 싶다면 즉시로딩으로 설정해주면 된다.

JPA 구현체(하이버네이트)는 즉시로딩을 사용하면 조인을 이용해서 하나의 SQL문에 최대한 많은 테이블을 가져온다.

@Entity
public class Member {

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "TEAM_ID")
    private Team team;
}

쿼리 하나로 Member와 Team을 다 가져온다.

 

✔ 되도록이면 모든 연관관계를 지연 로딩(LAZY)로 사용하자.

모든 연관 관계는 되도록이면 Lazy로 설정해서 사용하자.

• @ManyToOne, @OneToOne ➡ 즉시로딩(Eager)를 기본 값으로 제공
• @OneToMany, @ManyToMany ➡ 지연로딩(Lazy)를 기본 값으로 제공

위의 쿼리문을 보면 알겠지만, JPA 특성상 즉시로딩은 전혀 예상하지 못한 SQL문을 발생시킨다.

만약 참조가 10개라면, Member 한번 조회로 테이블 10개를 조인하는 정신나간 쿼리가 발생할 수 있다.

 

또한 즉시로딩은 JPQL을 사용할 때 N+1 문제를 일으키기 쉽다.

// 1. JPQL을 사용하면 즉시 flush되어 Member를 DB에서 가져온다
em.createQurey("select m from Member m", Member.class);

// 2. 그런데 Member안에 있는 Team이 즉시로딩이다. 값을 바로 가져와야한다.
// 3. 각각의 Member는 다른 Team 값을 가진다. 만약 Member가 10개면 Team 쿼리도 10개가 발생한다.
// SQL : select * from Team where TEAM_ID = xxx.. 쿼리가 멤버 개수만큼 발생.
@Entity
public class Member {

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn
    private Team team;
}

즉 난 쿼리1번을 날렸는데, 실제 쿼리는 1+N번 (Team을 조회하는 쿼리 N개)가 발생하는 개판이 발생할 수 있다.

지연로딩 (Lazy)를 사용하면 이런 일이 없다. Team을 사용하는 순간까지 미루다가 사용하는 시점에 쿼리 하나만 나간다.

 

만약 Member와 Team을 함께 가져오고 싶다면 JPA의 fetch join을 이용하도록 하자.

이는 SQL문에 존재하는 문법은 아니고, 연관된 엔티티(컬렉션)을 같이 조회한 뒤에 객체 필드에 set으로 연결하는 방법.

// join fetch 조인경로
em.createQuery("select m from Member m join fetch m.team", Member.class)

이렇게 Member가 사용하는 Team을 미리 한꺼번에 가져온다.

패치 조인을 통해 연관된 Team을 이미 영속성 컨텍스트로 가져왔으므로, 이후 호출하더라도 쿼리가 발생하지 않는다.

List<Member> list = 
    em.createQuery(jpql "select m from Member m join fetch m.team", Member.class).getResultList();

for(Member m : list){
    System.out.println(m.getTeam().getName()); // LAZY 로딩 발생 안함
}

 

그 외 엔티티 그래프 애노테이션이나 배치사이즈를 이용하는 방법이 있긴한데, 이는 나중에 알아보도록 하자.

 

 

📌 영속성 전이, @OneToMany( casecade= ~ ) 옵션

일단 스포부터 하자면, 영속성 전이는 연관관계를 매핑하는 것과 아무런 관계가 없다.

엔티티를 영속화 할 때, 연관된 다른 객체도 함께 영속화하는 편의도구이다. 

• Parent와 Child의 라이프사이클이 같아서, 한꺼번에 통으로 저장/ 삭제하고 싶을 때 사용.
• 소유자가 1개 (Parent - Child) 에서만 사용하고, 만약 Child를 쓰는 곳이 여러 곳이라면 절대 쓰면 안된다.
  저 멀리서 수정을 했는데, 내 엔티티에 변경이 전파되면 큰일난다.

엔티티를 영속화 할 때, 연관된 엔티티도 함께 영속화하는 편의도구이다. 종류는 아래와 같이 6개가 존재한다.

• ALL 모두 적용 - 모든 전파를 적용
• PERSIST 영속만 - 저장할 때에만 전파 사용
  * cascade로 영속화를 시도하는 객체가 이미 DB에 키값이 존재한다면 PersistentObjectException 가 발생한다.

다만 위 2가지만 자주 사용하고, 아래 4가지는 거의 사용하지 않는다.

• REMOVE 삭제만 - 부모를 삭제하면 밑에 자식도 모두 삭제가 전파됨
• MERGE 병합만 - 트랜잭션이 종료되고 준영속 상태에서 엔티티를 추가하거나, 부모가 merge()를 사용한 경우
• RERESH 리프레시만 - 엔티티를 새로 고칠 때, 이 필드에 보유 된 엔티티도 새로고침함.
• DETACH 준영속만 - 부모가 detach()로 준영속상태가 되면, 자식도 모두 준영속화됨. 

 

이는 예제를 보면 쉽게 이해할 수 있다. 아래 코드를 보자

@Entity
public class Child {

    @ManyToOne
    @JoinColumn("PARENT_ID")
    private Parent parent;

    public void setParent(Parent parent) {
        this.parent = parent;
    }
}

@Entity
public class Parent {

    @OneToMany(mappedBy = "parent")
    private List<Child> childList = new ArrayList<>();

    public void addChild(Child child) {
        childList.add(child);
        child.setParent(this); // 연관관계 설정
    }
}

 

이 코드를 기존의 JPA로 사용하면 아래와 같이 하나하나 persist() 해줘야 한다.

Child childOne = new Child();
Child childTwo = new Child();

Parent parent = new Parent();
parent.addChild(childOne);
parent.addChild(childTwo);

entityManager.persist(parent);
entityManager.persist(childOne);
entityManager.persist(childTwo);

 

이를 Parent에서 아래와 같이 Cascade를 ALL로 설정해주면

@Entity
public class Parent {

    @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL)
    private List<Child> childList = new ArrayList<>();
    ...
}

 

parent 가 참조하는 모든 객체는 함께 영속화된다.

Child childOne = new Child();
Child childTwo = new Child();

Parent parent = new Parent();
parent.addChild(childOne);
parent.addChild(childTwo);

// cascade = ALL 이라서 parent 내부에있는 모든 child도 함께 영속화됨.
entityManager.persist(parent);
// entityManager.persist(childOne);
// entityManager.persist(childTwo);

실제 DB에도 잘 들어가있다.

 

예를 들어 주문과 배달이 있을 때, [주문이 배달의 생명주기를 관리하고 싶다면] 아래와 같이 설정해줄 수 있다.

물론 이는 비즈니스 상황에 따라서 다르다. 주문이 삭제되어도 별도의 배달 기록만 남기고 싶을 수도 있으니까.

 // 이제 Order와 Delivery는 같은 생명주기를 공유한다.
@OneToMany(mappedBy = "parent", cascade = ALL)
private List<Delivery> Deliverys = new ArrayList<>();

 

 

📌 @OneToMany(orphanRemoval = true) , 고아 객체 삭제

말이 좀 슬픈데, 부모 엔티티와 관계가 끊어진 자식 엔티티를 삭제하는 기능이다.

• 반드시 참조하는 곳이 하나일 때 사용해야한다. GC처럼 참조 추적해주는 기능은 없다.
• @OneToOne, @OneToMany만 가능하며 특정 엔티티가 개인 소유(한 객체만 참조)일 때 사용한다.
  * 참고로 Parent를 통으로 삭제하면 cascade = REMOVE 처럼 동작한다. 모든 자식 객체를 삭제한다.

@Entity
public class Parent {

    @OneToMany(mappedBy = "parent", orphanRemoval = true) // 설정
    private List<Child> childList = new ArrayList<>();
    ...
}

Parent parent1 = em.find(Parent.class, id); 
parent1.getChildren().remove(0); // Parent에서 Child의 연관관계를 끊었다.

// orphanRemoval = true인 경우, 바로 Child가 DB에서 삭제됨
DELETE FROM Child WHERE ID=0

 

✔ 꿀팁 (부모가 자식객체의 생명주기 관리)

참고로 아래와 같이 ALL + orphanRemoval을 함께 사용하면 부모객체가 자식객체의 생명주기를 완전히 관리할 수 있다.

즉 이렇게하면 부모 객체만 Repository에 연결되어있으면 자식 객체용 Repository는 구현할 필요가 없다.

➡ 이는 도메인 주도 설계(DDD)에서 Aggregate Root 개념을 구현할 때 유용하게 사용된다.
Repository는 오직 Aggregate Root만 연결되어있고, Root가 모든 객체의 생명주기를 관리하도록 만들 수 있다.

@OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, orphanRemoval = true)
private List<Child> childList = new ArrayList<>();