[자바 ORM 표준 JPA 프로그래밍] 프록시와 연관관계 관리

프록시

프록시 객체

• 지연 로딩 기능을 사용하려면 실제 엔티티 객체 대신에 데이터베이스 조회를 지연할 수 있는 가짜 객체가 필요한데 이것을 프록시 객체라 한다.

참고

• JPA 표준 명세는 지연 로딩의 구현 방법을 JPA 구현체에 위임했다.

프록시 기초

프록시 특징

• 실제 클래스를 상속 받아서 만들어지므로 실제 클래스와 겉 모양이 같다. 따라서 이것이 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 된다.
• 실제 객체에 대한 참조(target)을 보관한다.
• 프록시 객체의 메소드를 호출하면 프록시 객체는 실제 객체의 메소드를 호출한다.
• 처음 사용할 때 한 번만 초기화된다.
• 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해도 프록시가 아닌 실제 엔티티를 반환한다.
• 초기화는 영속성 컨텍스트의 도움을 받아야 가능하다. 따라서 준영속 상태의 프록시를 초기화하면 문제가 발생한다. (`LazyInitializationException 예외)

프록시 객체의 초기화

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

프록시와 식별자

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

식별자 값을 조회하는 team.getId()를 호출해도 프록시를 초기화하지 않는다.

단, 엔티티 접근 방식을 프로퍼티(@Access(AccessType.PROPERTY))로 설정한 경우에만 초기화하지 않는다.

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

참고로 연관관계를 설정할 때는 엔티티 접근 방식을 필드로 설정해도 프록시를 초기화하지 않는다.

프록시 확인

JPA가 제공하는 PersistenceUnitUtil.isLoaded(Object entity) 메소드를 사용하면 프록시 인스턴스의 초기화 여부를 확인할 수 있다.

출력했을 때 클래스 명 뒤에 ..javassist..라 되어 있으면 이것은 프록시이다.

즉시 로딩과 지연 로딩

즉시 로딩

@ManyToOne(fetch = FetchType.EAGER)

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

NULL 제약조건과 JPA 조인 전략

• @JoinColumn에 nullable = false을 설정해서 이 외래 키는 NULL 값을 허용하지 않는다고 알려주면 JPA는 외부 조인 대신에 내부 조인을 사용한다.
• nullable = true: 외부 조인 사용 (기본값)
• nullable = false: 내부 조인 사용
• @ManyToOne.optional = false로 설정해도 내부 조인을 사용한다.
• JPA는 선택적 관계면 외부 조인, 필수 관계면 내부 조인을 사용한다.

지연 로딩

@ManyToOne(fetch = FetchType.LAZY)

지연 로딩을 사용하면 회원을 조회할 때 조회한 회원의 team 멤버변수에 프록시 객체를 넣어둔다.

실제 데이터가 필요한 순간이 되어서야 데이터베이스를 조회해서 프록시 객체를 초기화한다.

즉시 로딩, 지연 로딩 정리

처음부터 연관된 엔티티를 모두 영속성 컨텍스트에 올려두는 것은 현실적이지 않고, 필요할 때마다 SQL을 실행해서 연관된 엔티티를 지연 로딩하는 것도 최적화 관점에서 보면 꼭 좋은 것만은 아니다.

즉시 로딩과 지연 로딩의 사용은 상황에 따라 다르다.

지연 로딩 활용

프록시와 컬렉션 래퍼

컬렉션 래퍼

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

member.getOrder()를 호출해도 컬렉션은 초기화되지 않는다.

member.getOrder().get(0)처럼 컬렉션에서 실제 데이터를 조회할 때 데이터베이스를 조회해서 초기화한다.

JPA 기본 페치 전략

fetch 속성의 기본 설정값

• @ManyToOne, @OneToOne: 즉시 로딩
• @OneToMany, @ManyToMany: 지연 로딩

추천하는 방법은 모든 연관관계에 지연 로딩을 사용하는 것이다.

그리고 애플리케이션 개발이 어느 정도 완료단계에 왔을 때 실제 사용하는 상황을 보고 꼭 필요한 곳에만 즉시로딩을 사용하도록 최적화하면 된다.

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

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

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

영속성 전이: CASCADE

JPA에서 엔티티를 저장할 때 연관된 모든 엔티티는 영속 상태여야 한다.

영속성 전이: 저장

@OneToMany(mappedBy = "parent", cascade = CascadeType.PERSIST)

부모를 영속화할 때 연관된 자식들도 함께 영속화하라고 cascade = CascadeType.PERSIST 옵션을 설정한다.

영속성 전이: 삭제

CascadeType.REMOVE로 설정하고 부모 엔티티를 삭제하면 연관된 자식 엔티티도 함꼐 삭제 된다.

삭제 순서는 외래 키 제약조건을 고려해서 자식을 먼저 삭제하고 부모를 삭제한다.

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

CASCADE 종류

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

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

고아 객체

고아 객체 제거

• 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제하는 JPA에서 제공하는 기능

이 기능을 사용해서 부모 엔티티의 컬렉션에서 자식 엔티티의 참조만 제거하면 자식 엔티티가 자동으로 삭제된다.

@OneToMany(mappedBy = "parent", orphanRemoval = true)

고아 객체 제거 기능은 플러시 시점에 DELETE SQL이 실행된다.

참조하는 곳이 하나일 떄만 사용해야 한다. 그래서 orphanRemoval은 @OneToOne, @OneToMany에만 사용할 수 있다.

개념적으로 볼때 부모를 제거하면 자식은 고아가 된다. 이것은 CascadeType.REMOVE를 설정한 것과 같다.

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

CascadeType.ALL + orphanRemoval = true를 동시에 사용하면 어떻게 될까?

일반적으로 엔티티는 스스로 생명주기를 관리한다. 그런데 두 옵션을 모두 활성화하면 부모 엔티티를 통해서 자식의 생명주기를 관리할 수 있다.