Chap.8 프록시와 연관관계 관리

프록시와 즉시로딩, 지연로딩

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

영속성 전이와 고아 객체

- JPA는 연관된 객체를 함께 저장하거나 함께 삭제할 수 있는 영속성 전이와 고아 객체 제거라는 편리한 기능을 제공한다.

 

프록시

- 엔티티를 조회할 때 연관된 엔티티들이 항상 사용되는 것은 아니다. JPA는 이런 문제를 해결하려고 엔티티가 실제 사용될 때까지 데이터베이스 조회를 지연하는 방법을 제공하는데 이것을 지연 로딩이라 한다. 그런데 지연 로딩 기능을 사용하려면 실제 엔티티 객체 대신에 데이터베이스 조회를 지연할 수 있는 가짜 객체가 필요한데 이것을 프록시 객체라 한다.

JPA 표준 명세는 지연 로딩의 구현 방법을 JPA 구현체에 위임했다. 따라서 지금부터 설명할 내용은 하이버네이트 구현체에 대한 내용이다. 하이버네이트는 지연 로딩을 지원하기 위해 프록시를 사용하는 방법과 바이트코드를 수정하는 두 가지 방법을 제공하는데 바이트코드를 수정하는 방법은 설정이 복잡하므로 여기서는 별도의 설정이 필요 없는 프록시에 대해서만 알아보겠다. 바이트코드를 수정하는 방법은 하이버네이트 공식 사이트를 참고하자.

 

프록시 기초

- 엔티티를 실제 사용하는 시점까지 데이터베이스 조회를 미루고 싶으면 EntityManager.getReference() 메소드를 사용하면 된다. 이 메소드를 호출할 때 JPA는 데이터베이스를 조회하지 않고 실제 엔티티 객체도 생성하지 않는다. 대신에 데이터베이스 접근을 위임한 프록시 객체를 반환한다.

 

프록시 특징

- 프록시 클래스는 실제 클래스를 상속 받아서 만들어지므로 실제 클래스와 겉 모양이 같다. 따라서 사용하는 입장에서는 이것이 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 된다.

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

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

- 프록시 객체를 초기화한다고 프록시 객체가 실제 엔티티로 바뀌는 것은 아니다. 프록시 객체가 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근할 수 있다.

- 프록시 객체는 원본 엔티티를 상속받은 객체이므로 타입 체크 시에 주위해서 사용해야 한다.

- 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 데이터베이스를 조회할 필요가 없으므로 em.getReference()를 호출해도 프록시가 아닌 실제 엔티티를 반환한다.

- 초기화는 영속성 컨텍스트의 도움을 받아야 가능하다. 따라서 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태의 프록시를 초기화하면 문제가 발생한다. 하이버네이트는 org.hibernate.LazyInitailizationException 예외를 발생시킨다.

 

프록시 객체의 초기화

- 프록시 객체는 member.getName() 처럼 실제 사용될 때 데이터베이스를 조회해서 실제 엔티티 객체를 생성하는데 이것을 프록시 객체의 초기화라 한다.

1) 프록시 객체에 member.getName()을 호출해서 실제 데이터를 조회한다.

2) 프록시 객체는 실제 엔티티가 생성되어 있지 않으면 영속성 컨텍스트에 실제 엔티티 생성을 요청하는데 이것을 초기화라 한다.

3) 영속성 컨텍스트는 데이터베이스를 조회해서 실제 엔티티 객체를 생성한다.

4) 프록시 객체는 생성된 실제 엔티티 객체의 참조를 Member target 멤버변수에 보관한다.

5) 프록시 객체는 실제 엔티티 객체의 getName()을 호출해서 결과를 반환한다.

 

준영속 상태와 초기화

- em.close() 메소드로 영속성 컨텍스트를 종료해서 준영속 상태가 되면 프록시를 초기화할 때 영속성 컨텍스트가 없으므로 실제 엔티티를 조회할 수 없어서 예외가 발생한다.

JPA 표준 명세는 지연로딩(프록시)에 대한 내용을 JPA 구현체에 맡겼다. 따라서 준영속 상태의 엔티티를 초기화할 때 어떤 일이 발생할지 표준 명세에는 정의되어 잇지 않다. 하이버네이트를 사용하면 org.hibernate.LazyInitializationException 예외가 발생한다.

 

프록시와 식별자

- 엔티티를 프록시로 조회할 때 식별자(PK) 값을 파라미터로 전달하는데 프록시 객체는 이 식별자 값을 보관한다. 프록시 객체는 식별자 값을 가지고 있으므로 식별자 값을 조회하는 team.getId()를 호출해도 프록시를 초기화하지 않는다. 단 엔티티 접근 방식을 프로퍼티(@Access(AccessType.PROPERTY))로 설정한 경우에만 초기화하지 않는다. 엔티티 접근 방식을 필드로 설정하면 JPA는 getId() 메소드가 id만 조회하는 메소드인지 다른 필드까지 활용해서 어떤 일을 하는 메소드인지 알지 못하므로 프록시 객체를 초기화한다.

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

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

Member member = em.find(Member.class, "member1");
Team team = em.getReference(Team.class, "team1"); // SQL을 실행하지 않음
member.setTeam(team);

 

프록시 확인

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

booelan isLoad = em.getEntityMangerFactory().getPersistenceUnitUtil().isLoaded(entity);
// boolean isLoad = emf.getPersistenceUnitUtil().isLoaded(entity);

- 조회한 엔티티가 진짜 엔티티인지 프록시로 조회한 것인지 확인하려면 클래스명을 직접 출력해보면 된다. 다음 예를 보면 클래스 명 뒤에 ...javassist...라 되어 있는데 이것으로 프록시인 것을 확인할 수 있다. 프록시를 생성하는 라이브러리에 따라 출력 결과는 달라질 수 있다.

System.out.println("memberProxy = " + member.getClass().getName();
// 결과: memberProxy = jpabook.domain.Member_$$_javassist_0

프록시 강제 초기화

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

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

JPA 표준에는 프록시 강제 초기화 메소드가 없다. 따라서 강제로 초기화하려면 member.getName()처럼 프록시의 메소드를 직접 호출하면 된다. JPA 표준은 단지 초기화 여부만 확인할 수 있다.

 

즉시 로딩과 지연 로딩

- 프록시 객체는 주로 연관된 엔티티를 지연 로딩할 때 사용한다.

- JPA는 개발자가 연관된 엔티티의 조회 시점을 선택할 수 있도록 다음 두 가지 방법을 제공한다.

1) 즉시 로딩: 엔티티를 조회할 때 연관된 엔티티도 함께 조회한다.

ex) @ManyToOne(fetch = FetchType.EAGER)

2) 지연 로딩: 연관된 엔티티를 실제 사용할 때 조회한다.

ex) @ManyToOne(fetch = FetchType.LAZY)

 

즉시 로딩

- 대부분의 JPA 구현체는 즉시 로딩을 최적화하기 위해 가능하면 조인 쿼리를 사용해서 즉시 로딩한다.

NULL 제약조건과 JPA 조인 전략

@JoinColumn(nullable = true): NULL 허용(기본값), 외부 조인 사용

@JoinColumn(nullable = false): NULL 허용하지 않음, 내부 조인 사용

@ManyToOne(fetch = FetchType.EAGER, optional = false)

 

지연 로딩

- 프록시 객체는 실제 사용될 때까지 데이터 로딩을 미루는 것을 지연 로딩이라 한다. 실제 데이터가 필요한 순간이 되어서야 데이터베이스를 조회해서 프록시 객체를 초기화한다.

Team team = member.getTeam(); // 프록시 객체
team.getName(); // 팀 객체 실제 사용

 

즉시 로딩, 지연 로딩 정리

- 처음부터 연관된 엔티티를 모두 영속성 컨텍스트에 올려두는 것은 현실적이지 않고, 필요할 때마다 SQL을 실행해서 연관된 엔티티를 진연 로딩하는 것도 최적화 관점에서 보면 꼭 좋은 것만은 아니다. 예를 들어 대부분의 애플리케이션 로직에서 회원과 팀 엔티티를 같이 사용한다면 SQL 조인을 사용해서 회원과 팀 엔티티를 한번에 조회하는 겻이 더 효율적이다. 결국 연관된 엔티티를 즉시 로딩하는 것이 좋은지 아니면 실제 사용할 때까지 지연해서 로딩하는 것이 좋은지는 상황에 따라 다르다.

- 지연 로딩(LAZY): 연관된 엔티티를 프록시로 조회한다. 프록시를 실제 사용할 때 초기화하면서 데이터베이스를 조회한다.

- 즉시 로징(EAGER): 연관된 엔티티를 즉시 조회한다. 하이버네이트는 가능하면 SQL 조인을 사용해서 한 번에 조회한다.

 

프록시와 컬렉션 래퍼

- 지연 로딩으로 설정하면 실제 엔티티 대신에 프록시 객체를 사용한다. 프록시 객체는 실제 자신이 사용될 때까지 데이터베이스를 조회하지 않는다.

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

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

- member.getOrders()를 호출해도 컬렉션은 초기화되지 않는다. 컬렉션은 member.getOrders().get(0)처럼 컬렉션에서 실제 데이터를 조회할 때 데이터베이스를 조회해서 초기화한다.

 

JPA 기본 페치 전략

- fetch 속성의 기본 설정값은 다음과 같다.

@ManyToOne, @OneToOne: 즉시 로딩(FetchType.EAGER)

@OneToMany, @ManyToMany: 지연 로딩(FetchType.LAZY)

- JPA의 기본 페치 전략은 연관된 엔티티가 하나면 즉시 로딩을, 컬렉션이면 지연 로딩을 사용한다. 컬렉션을 로딩하는 것은 비용이 많이 들고 잘못하면 너무 많은 데이터를 로딩할 수 있기 때문이다.

- 추천하는 방법은 모든 연관관계에 지연 로딩을 사용하는 것이다. 그리고 애플리케이션 개발이 어느 정도 완료돤계에 왔을 때 실제 사용하는 상황을 보고 꼭 필요한 곳에만 즉시 로딩을 사용하도록 최적화하면 된다.

 

컬렉션에 FetchType.EAGER 사용 시 주의점

- 컬렉션을 하나 이상 즉시 로딩하는 것은 권장하지 않는다.

: 서로 다른 컬렉션을 2개 이상 조인할 때 발생하는 데 예를 들어 A 테이블을 N, M 두 테이블과 일대다 조인하면 SQL 실행 결과가 N 곱하기 M이 되면서 너무 많은 데이터를 반환할 수 있고 결과적으로 애플리케이션 성능이 저하될 수 있다. JPA는 이렇게 조회된 결과를 메로리에서 필터링해서 반환한다. 따라서 2개 이상의 컬렉션을 즉시 로딩으로 설정하는 것은 권장하지 않는다.

- 컬렉션 즉시 로딩은 항상 외부 조인(OUTER JOIN)을 사용한다.

: 예를 들어 다대일 관계인 회원 테이블과 팀 테이블을 조인할 때 회원 테이블의 외래 키에 not null 제약조건을 걸어두면 모든 회원은 팀에 소속되므로 항상 내부 조인을 사용해도 된다. 반대로 팀 테이블에서 회원 테이블과 일대다 관계를 조인할 때 회원이 한 명도 없는 팀을 내부 조인하면 팀까지 조회되지 않는 문제가 발생한다. 데이터베이스 제약조건으로 이런 상황을 막을 수는 없다. 따라서 JPA는 일대다 관계를 즉시 로딩할 때 항상 외부 조인을 사용한다.

- @ManyToOne, @OneToOne

: (optional = false): 내부 조인

: (optioanl  = true): 외부 조인

- @OneToMany, @ManyToMany

: (optional = false): 외부 조인

: (optioinal = true): 외부 조인

 

영속성 전이: CASCADE

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

- JPA에서 엔티티를 저장할 때 연관된 모든 엔티티는 영속 상태여야 한다. 따라서 예제를 보면 부모 엔티티를 영속 상태로 만들고 자식 엔티티도 각각 영속 상태로 만든다. 이럴 때 영속성 전이를 사용하면 부모만 영속 상태로 만들면 연관된 자식까지 한 번에 영속 상태로 만들 수 있다.

pirvate static void saveNoCascade(EntityManager em) {
// 부모 저장
Parent parent = new Parent();
em.persist(parent);

// 1번 자식 저장
Child child1 = new Child();
child1.setParent(parent); // 자식 -> 부모 연관관계 설정
parent.getChildren().add(child1); // 부모 -> 자식
em.persist(child1);

// 2번 자식 저장
Child child2 = new Child();
child2.setParent(parent); // 자식 -> 부모 연관관계 설정
parent.getChildren().add(chid2); // 부모 -> 자식
em.persist(child2);
}

 

영속성 전이: 저장

- 영속성 전이를 활성화하는 CASCADE 옵션을 적용해보자. 이 옵션을 적용하면 간편하게 부모와 자식 엔티티를 한 번에 영속화할 수 있다. 부모만 영속화하면 CascadeType.PERSIST로 설정한 자식 엔티티까지 함께 영속화해서 저장한다.

- 영속성 전이는 연관관계를 매핑하는 것과는 아무 관련이 없다. 단지 엔티티를 영속화할 때 연관된 엔티티도 같이 영속화하는 편리함을 제공할 뿐이다.

@Entity
public class Parent {
...
@OneToMany(mappedBy = "parent", cascade = CascadeType.PERSIST)
private List<Child> children = new ArrayList<Child>();
...
}

 

영속성 전이: 삭제

- 저장한 부모와 자식 엔티티를 모두 제거하려면 다음 코드와 같이 각각의 엔티티를 하나씩 제거해야 한다.

- 영속성 전이는 엔티티를 삭제할 때도 사용할 수 있다. CascadeType.REMOVE로 설정하고 다음 코드처럼 부모 엔티티만 삭제하면 연관된 자식 엔티티도 함께 삭제된다. 삭제 순서는 외래 키 제약조건을 고려해서 자식을 먼저 삭제하고 부모를 삭제한다. CascadeType.REMOVE를 설정하지 않고 이 코드를 실행하면 부모엔티티만 삭제되어 자식 테이블에 걸려 있는 외래 키 제약조건으로 인해, 데이터베이스에서 외래 키 무결성 예외가 발생한다.

 

CASCADE의 종류

- 다음처럼 여러 속성을 같이 사용할 수 있다.

cascade = {CascadeType.PERSIST, CascadeType.REMOVE}

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

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

 

고아 객체

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

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

- 고아 객체 제거에는 기능이 하나 더 있는데 개념적으로 볼때 부모를 제거하면 자식은 고아가 된다. 따라서 부모를 제거하면 자식도 같이 제거된다. 이것은 CascadeType.REMOVE를 설정한 것과 같다.

@OneToMany(mappedBy = "parent", orpahnRemoval = true)
private List<Child> children = new ArrayList<Child>();

 

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

- CascadeType.ALL + orpahnRemoval = true를 동시에 사용하면 부모 엔티티를 통해서 자식의 생명주기를 관리할 수 있다. 일반적으로 엔티티는 EntityManager.persist()를 통해 영속화되고 EntityManger.remove()를 통해 제거된다. 이것은 엔티티 스스로 생명주기를 관리한다는 뜻이다.

- 자식을 저장하려면 부모에 등록만 하면 된다(CASCADE)

Parent parent = em.find(Parent.calss, parentId);
parent.addChild(child1);

- 자식을 삭제하려면 부모에서 제거하면 된다(orpahnRemoval)

Parent parent = em.find(Parent.calss, parentId);
parent.getChildren().remove(removeObject);

영속성 전이는 DDD의 Aggregate Root 개념을 구현할 때 사용하면 편리하다.

 

정리

- JPA 구현체들은 객체 그래프를 마음껏 탐색할 수 있도록 지원하는데 이때 프록시 기술을 사용한다.

- 객체를 조회할 때 연관된 객체를 즉시 로딩하는 방법을 즉시 로딩이라 하고, 연관된 객체를 지연해서 로딩하는 방법을 지연 로딩이라 한다.

- 객체를 저장하거나 삭제할 때 연관된 객체도 함께 저장하거나 삭제할 수 있는데 이것을 영속성 전이라 한다.

- 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제하려면 고아 객체 제거 기능을 사용하면 된다.