[JPA] 프록시와 연관관계 관리

애이용·2021년 9월 8일
0

JPA

목록 보기
1/2
post-thumbnail

객체는 객체 그래프로 연관된 객체들을 탐색한다.

객체가 데이터베이스에 저장되어 있으므로 연관된 객체를 마음껏 탐색하기는 어렵다. JPA 구현체들은 이 문제를 해결하려고 프록시라는 기술을 사용한다.
프록시를 사용하면 연관된 객체를 처음부터 데이터베이스에서 조회하는 것이 아니라, 실제 사용하는 시점에 데이터베이스에서 조회할 수 있다.
하지만 자주 함께 사용하는 객체들은 조인을 사용해서 함께 조회하는 것이 효과적이다. JPA는 지연로딩, 즉시로딩을 모두 지원한다.

엔티티를 조회할 때 연관된 엔티티들이 항상 사용되는 것이 아니다. 예를 들어 회원 엔티티를 조회할 때 연관된 팀 엔티티는 비지니스 로직에 따라 사용될 때도 있지만 그렇지 않을 때도 있다.

    public static void printUserAndTeam(EntityManager em, Long memberId) {
        Member member = em.find(Member.class, memberId);
        Team team = member.getTeam();
        System.out.println("회원 이름: " + member.getUsername());
        System.out.println("소속팀: " + team.getName());
    }

위의 메서드는 회원과 팀 모두 조회하는 비즈니스 로직이다. 회원 정보는 물론, 연관된 팀 엔티티도 조회한다.

    public static void printUser(EntityManager em, Long memberId) {
        Member member = em.find(Member.class, memberId);
        System.out.println("회원 이름: " + member.getUsername());
    }

위의 메서드는 회원 엔티티만 사용하므로, 연관된 팀 엔티티까지 데이터베이스에서 함께 조회해 두는 것은 효율적이지 않다.
이 문제를 해결하고자 JPA는 엔티티를 사용할때까지 데이터베이스 조회를 지연하는 방법을 제공하는데 이 방법을 지연로딩이라 부른다. 지연 로딩 기능을 사용하려면 실제 엔티티 객체 대신에 데이터베이스 조회를 지연할 수 있는 가짜 객체가 필요한데 이것을 프록시 객체라고 한다.

프록시 객체

JPA에서 식별자로 엔티티 하나 를 조회할 때는 EntityManager.find()를 사용한다. 이 메서드는 영속성 컨텍스트에 엔티티가 없으면 데이터베이스를 조회한다.

Member member = em.find(Member.class, "member1");

이렇게 엔티티를 직접 조회하면 조회한 엔티티를 실제 사용하든 사용하지 않든, 데이터베이스를 조회하게 된다.
엔티티를 실제 사용하는 시점까지 데이터베이스 조회를 미루고 싶으면 EntityManager.getReference() 메서드를 사용하면 된다.

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

이 메서드를 호출할 때 JPA는 데이터베이스를 조회하지 않고, 실제 엔티티 객체도 생성하지 않는다. 대신에 데이터베이스 접근을 위임한 프록시 객체를 반환한다.

프록시 객체는 실제 객체에 대한 참조(target)을 보관한다. 그리고 프록시 객체의 메서드를 호출하면 프록시 객체는 실제 객체의 메서드를 호출한다.

  • 프록시 객체의 초기화
    프록시 객체는 member.getName() 처럼 실제 사용될 때 데이터베이스를 조회해서 실제 엔티티 객체를 생성하는데 이것을 프록시 객체의 초기화라고 한다.
// MemberProxy 반환
Member member = em.getReference(Member.class, "id1");
member.getName(); // getName();
  • 프록시 클래스 예상 코드
public class MemberProxy extends Member{
  Member target = null; // 실제 엔티티 참조
  public String getName(){
    if(target == null){
      // 초기화 요청
      // DB 조회
      // 실제 엔티티 생성 및 참조 보관
      this.target = ...;
    }
    return target.getName();
  }
}
  • 프록시 초기화 과정
  1. 프록시 객체에 member.getName()을 호출해서 실제 데이터를 조회한다.
  2. 프록시 객체는 실제 엔티티가 생성되어 있지 않으면 영속성 컨텍스트에 실제 엔티티 생성을 요청하는데 이것을 초기화라 한다.
  3. 영속성 컨텍스트는 데이터베이스를 조회해서 실제 엔티티 객체를 생성한다.
  4. 프록시 객체는 생성된 실제 엔티티 객체의 참조를 Member target 멤버변수에 보관한다.
  5. 프록시 객체는 실제 엔티티 객체의 getName()을 호출해서 결과를 반환한다.
  • 프록시 특징
    • 프록시 객체는 처음 사용할 때 한 번만 초기화된다.
    • 프록시 객체를 초기화한다고 프록시 객체가 실제 엔티티로 바뀌는 것이 아니다. 프록시 객체가 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근할 수 있다.
    • 프록시 객체는 원본 엔티티를 상속받은 객체이므로 타입 체크 시에 주의해서 사용해야 한다.
    • 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 데이터베이스를 조회할 필요가 없으므로 em.getReference()를 호출해도 프록시가 아닌 실제 엔티티를 반환한다.
    • 초기화는 영속성 컨텍스트의 도움을 받아야 가능하다. 따라서 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태의 프록시를 초기화하면 문제가 발생한다. 하이버네이트는 org.hibernate.LazyInitializationException 예외를 발생시킨다.
  • 준영속 상태와 초기화
// MemberProxy 반환
Member member = em.getReference(Member.class, "id1");
transaction.commit();
em.close(); // 영속성 컨텍스트 종료

member.getUsername(); 
// 준영속 상태 초기화 시도 org.hibernate.LazyInitializationException 예외 발생

em.close() 메서드로 영속성 컨텍스트를 종료해서 member는 준영속 상태이다. member.getName()을 호출하면 프록시를 초기화해야 하는데, 영속성 컨텍스트가 없으므로 엔티티를 조회할 수 없어 예외가 발생한다.

프록시와 식별자

엔티티를 프록시로 조회할 때 식별자(PK) 값을 파라미터로 전달하는데, 프록시 객체는 이 식별자 값을 보관한다.

Team team = em.getReference(Team.class, "team1"); // 식별자 보관
team.getId(); // 초기화되지 않음.

엔티티 접근 방식을 프로퍼티(@Access(AccessType.PROPERTY))로 설정한 경우에만 초기화되지 않는다.
접근 방식을 필드(@Access(AccessType.FIELD))로 설정하면 JPA는 getId() 메서드가 id만 조회하는 메서드인지, 다른 필드까지 활용해서 어떤 일을 하는 메서드인지 알지 못해서 프록시 객체를 초기화한다.

연관관계를 설정할 때는 식별자 값만 사용하므로 프록시를 사용할 때 데이터베이스 접근 횟수를 줄일 수 있다. 참고로 연관관계를 설정할 때는 엔티티 접근 방식을 필드로 설정해도 프록시를 초기화하지 않는다.

Member member = em.find(Member.class, "member1");
Team team = em.getReference(Team.class, "team1");
member.setTeam(team); // 연관관계 설정해도 초기화하지 않음. 

프록시 확인

JPA가 제공하는 PersistenceUnitUtil.isLoaded(Object entity) 메서드를 사용하면 프록시 인스턴스의 초기화 여부를 확인할 수 있다. (초기화되지 않으면 false 반환)
이미 초기화되었거나, 프록시 인스턴스가 아니면 true 반환한다.

boolean isLoad = em.getEntityManagerFactory().getPersistenceUnitUtil().isLoaded(entity);
System.out.println("isLoad = " + isLoad); // 초기화 여부 확인

프록시 강제 초기화

하이버네이트의 initialize() 메서드를 사용하면 프록시를 강제로 초기화할 수 있다.

org.hibernate.Hibernate.initialize(order.getMember()); // 프록시 초기화

JPA 표준에는 프록시 강제 초기화 메서드가 없다. 강제로 초기화하려면 프록시의 메서드를 직접 호출하면 된다.

즉시 로딩과 지연 로딩

  • 즉시 로딩: 엔티티를 조회할 때 연관된 엔티티도 함께 조회한다. (연관된 엔티티를 즉시 조회한다. 하이버네이트는 가능하면 SQL 조인을 사용해서 한 번에 조회한다.)
  • 지연 로딩: 연관된 엔티티를 실제 사용할 때 조회한다. (연관된 엔티티를 프록시로 조회한다.)

즉시 로딩

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

회원과 팀 두 테이블을 조회해야 하므로 쿼리를 2번 실행할 것 같지만, 대부분 JPA 구현체는 즉시 로딩을 최적화하기 위해 가능하면 조인 쿼리를 사용한다.

NULL 제약 조건과 JPA 조인 전략

즉시 로딩 실행 SQL에서 JPA는 내부 조인이 아닌 외부 조인(LEFT OUTER JOIN)을 사용했다. 현재 회원 테이블에 TEAM_ID 외래 키는 NULL 값을 허용하고 있어서 팀에 소속되지 않은 회원이 있을 수 있다.
팀에 소속하지 않은 회원과 내부 조인을 하면 팀은 물론, 회원 데이터도 조회할 수 없다.
JPA는 이런 상황을 고려해서 외부 조인을 사용한다. 하지만 외부 조인보다 내부 조인이 성능과 최적화에 유리하다. 내부 조인을 사용하려면 외래 키에 NOT NULL 제약 조건을 설정하면 된다. (값이 있는 것을 보장하기 때문이다.)

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

지연 로딩

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

조회 대상이 영속성 컨텍스트에 이미 있으면 프록시 객체를 사용할 이유가 없다. 따라서 프록시가 아닌 실제 객체를 사용한다. 예를 들어 team1 엔티티가 영속성 컨텍스트에 이미 로딩되어 있으면 프록시가 아닌 실제 team1 엔티티를 사용한다.

프록시와 컬렉션 래퍼

하이버네이트는 엔티티를 영속 상태로 만들 때 엔티티에 컬렉션이 있으면 컬렉션을 추적하고 관리할 목적으로 원본 컬렉션을 하이버네이트가 제공하는 내장 컬렉션으로 변경하는데 이것을 컬렉션 래퍼라고 한다. (org.hibernate.collection.internal.PersistentBag)

엔티티를 지연 로딩하면 프록시 객체를 사용해서 지연 로딩을 수행하지만, 주문 내역 같은 컬렉션은 컬렉션 래퍼가 지연 로딩을 처리해준다.
컬렉션 래퍼도 컬렉션에 대한 프록시 역할을 하므로 따로 구분하지 않고 프록시로 부르겠다.

@Entity
public class Member {
    // ...
    @ManyToOne(fetch = FetchType.EAGER)
    private Team team;   
    
    @OneToMany(mappedBy = "member", fetch = FetchType.LAZY)
    private List<Order> orders;
}

참고로 member.getOrders()를 호출해도 컬렉션은 초기화되지 않는다. 컬렉션은 member.getOrders().get(0)을 호출해서 연관된 주문 내역을 조회하면 어떻게 될까
주문 내역과 상품의 로딩 방법을 FetchType.EAGER로 설정했다면, 지연 로딩 상태인 주문 내역을 초기화할 때 연관된 상품도 함께 로딩한다.

JPA 기본 페치 전략

  • @ManyToOne, @OneToOne: 즉시 로딩(FetchType.EAGER)
  • @OneToMany, @ManyToMany: 지연 로딩(FetchType.LAZY)

컬렉션을 로딩하는 것은 비용이 많이 들고, 잘못하면 너무 많은 데이터를 로딩할 수 있다.
추천하는 방법은 모든 연관관계에 지연 로딩을 사용하는 것이다. 그리고 애플리케이션 개발이 어느 정도 완료 단게에 왔을 때 실제 사용하는 상황을 보고 꼭 필요한 곳에만 즉시 로딩을 사용하도록 최적화하면 된다.

참고로 SQL을 직접 사용하면 이런 유연한 최적화가 어렵다. 예를 들어 SQL로 각각의 테이블을 조회해서 처리하다가 조인으로 한 번에 조회하도록 변경하려면 많은 SQL과 애플리케이션 코드를 수정해야 한다.

컬렉션 즉시 로딩은 항상 외부 조인을 사용한다. 팀 테이블에서 회원 테이블로 일대다 관계를 조인할 때 회원이 한 명도 없는 팀을 내부 조인하면 팀까지 조회하지 않는 문제가 발생한다. 데이터베이스 제약 조건으로 이런 상황을 막을 수는 없기 때문에 JPA는 일대다 관게를 즉시 로딩할 때 항상 외부 조인을 사용한다.

FetchType.EAGER 설정과 조인 전략 정리

  • @ManyToOne, @OneToOne
    • (optional = false): 내부 조인
    • (optional = true): 외부 조인
  • @OneToMany, @ManyToMany
    • (optional = false): 외부 조인
    • (optional = true): 외부 조인

영속성 전이: CASCADE

저장

특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶으면 영속성 전이 기능을 사용하면 된다. JPA는 CASCADE 옵션으로 영속성 전이를 제공한다. 쉽게 말해 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장할 수 있다.

  • 부모 엔티티
@Entity
public class Parent {
    @Id @GeneratedValue
    private Long id;
    
    @OneToMany(mappedBy = "parent", cascade = CascadeType.PERSIST)
    private List<Child> children = new ArrayList<>();
    ...
}
  • 자식 엔티티
@Entity
public class Child {
    
    @Id @GeneratedValue
    private Long id;
    
    @ManyToOne
    private Parent parent; 
    
}
  • CASCADE 저장 코드
Child child1 = new Child();
Child child2 = new Child();

Parent parent = new Parent();
child1.setParent(parent); // 연관관계 추가
child2.setParent(parent); // 연관관계 추가
parent.getChildren().add(child1);
parent.getChildren().add(child2);

// 부모 저장, 연관된 자식들 저장
em.persist(parent);

삭제

CascadeType.REMOVE로 설정하면 부모 엔티티만 삭제하면 자식 엔티티도 함께 삭제한다.

만약 설정하지 않고 부모 엔티티를 삭제하면 데이터베이스의 부모 로우를 삭제하는 순간 자식 테이블에 걸려 있는 외래 키 제약조건으로 인해, 데이터베이스에서 외래키 무결성 예외가 발생한다.

CASCADE 종류

public enum CascadeType {
    ALL, 	// 모두 적용
    PERSIST,	// 영속
    MERGE,	// 병합
    REMOVE,	// 삭제
    REFRESH,	// REFRESH
    DETACH,	// DETACH
}

참고로 PERSIST, REMOVE는 em.persist(), em.remove()를 실행할 때 바로 전이가 발생하지 않고, 플러시를 호출할 때 전이가 발생한다.

고아 객체

JPA는 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제하는 기능을 제공하는데 이것을 고아 객체(ORPHAN) 제거라고 한다. 이 기능을 사용해서 부모 엔티티의 컬렉션에서 자식 엔티티의 참조만 제거하면 자식 엔티티가 자동으로 삭제되도록 해보자.

@Entity
public class Parent {

    @Id @GeneratedValue
    private Long id;
    
    @OneToMany(mappedBy = "parent", cascade = orphanRemoval = true)
    private List<Child> children = new ArrayList<>();
    ...
}

이제 컬렉션에서 제거한 엔티티는 자동으로 삭제된다.

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

// 모든 자식 엔티티를 제거하려면
parent1.getChildren().clear();

고아 객체 제거는 참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아 객체로 보고 삭제하는 기능이다. 따라서 이 기능은 참조하는 곳이 하나일 때만 적용해야 한다. 만약 삭제한 엔티티를 다른 곳에서도 참조한다면 문제가 발생할 수 있다. 이런 이유로 orphanRemoval은 @OneToOne, @OneToMany에만 사용할 수 있다.

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

CascadeType.ALL + orphanRemoval = true를 동시에 사용하면 어떻게 될까
일반적으로 엔티티는 em.persist()를 통해 영속화하고 em.remove()를 통해 제거된다. 이것은 엔티티 스스로 생명주기를 관리한다는 뜻이다. 이 두 옵션을 모두 활성화하면 부모 엔티티를 통해 자식의 생명주기를 관리할 수 있다.

// 자식을 저장하려면 부모에 등록만 하면 된다(CASCADE)
Parent parent = em.find(Parent.class, parentId);
parent.addChild(child1);

// 자식을 삭제하려면 부모에서 제거하면 된다(orphanRemoval)
Parent parent = em.find(Parent.class, parentId);
parent.getChildren().remove(removeObject);

핵심 정리

  • JPA 구현체들은 객체 그래프를 마음껏 탐색할 수 있도록 지원하는데 이때 프록시 기술을 사용한다.
  • 객체를 조회할 때 연관된 객체를 즉시 로딩하는 방법을 즉시 로딩이라 하고, 연관된 객체를 지연해서 로딩하는 방법을 지연 로딩이라고 한다.
  • 객체를 저장하거나 삭제할 때 연관된 객체도 함께 저장하거나 삭제할 수 있는데 이것을 영속성 전이라고 한다.
  • 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제하려면 고아 객체 제거 기능을 사용하면 된다.
profile
로그를 남기자 〰️

0개의 댓글