프록시와 연관관계 관리

728x90

1. 프록시

위 회원 정보만 출력하는 로직에서 em.find()로 회원 엔티티를 조회할 때 회원과 연관된 팀 엔티티까지 DB에서 함께 조회해 두는 것은 효율적이지 않다. JPA는 이런 문제를 해결하려고 엔티티가 실제 사용될때까지 DB 조회를 지연하는 방법을 제공하는데 이것을 지연 로딩이라고 한다. 그런데 지연 로딩을 사용하려면 실제 엔티티 객체 대신에 DB조회를 지연할 수 있는 가짜 객체가 필요한데 이것을 프록시 객체라 한다.

프록시 기초

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

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

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

- 프록시의 특징

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

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

- 프록시 객체의 초기화

프록시 객체는 member.getName()처럼 실제 사용될 때 DB를 조회해서 실제 엔티티 객체를 생성한다.

- 초기화 과정 분석

프록시 객체에 member.getName() 을 호출하여 실제 데이터를 조회한다.
프록시 객체는 실제 엔티티가 생성되어 있지 않으면 영속성 컨텍스트에 실제 엔티티 생성을 요청하는데 이것을 초기화라 한다.
영속성 컨텍스트는 DB를 조회해서 실제 엔티티 객체를 생성
프록시 객체는 생성된 실제 엔티티 객체의 참조를 Member target 멤버변수에 보관한다.
프록시 객체는 실제 엔티티 객체의 getName()을 호출해서 결과를 반환한다.

- 초기화 과정 분석

프록시 객체는 처음 사용할 때 한 번만 초기화된다.
프록시 객체를 초기화한다고 프록시 객체가 실제 엔티티로 바뀌는 것은 아니다. 프록시 객체가 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근할 수 있다.
프록시 객체는 원본 엔티티를 상속받은 객체이므로 타입 체크 시에 주의해야 한다.
영속성 컨텍스트에 찾는 엔티티가 이미 있으면 DB를 조회할 필요가 없으므로 em.getReference()를 호출해도 프록시가 아닌 실제 엔티티를 반환한다.
초기화는 영속성 컨텍스트의 도움을 받아야 가능하다. 따라서 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태의 프록시를 초기화하면 문제가 발생한다. 하이버네이트는 org.hibernate.LazyInitializationException 예외를 발생한다.

- 준영속 상태의 초기화

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

프록와 식별자

프록시 객체는 식별자(PK)값을 보관한다.

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

프록시를 사용하면 DB 접근 횟수를 줄일 수 있다.

프록시 확인

PersistenceUnitUtil.isLoaded(Object entity) 메서드를 사용하면 프록시 인스턴스의 초기화 여부를 확인할 수 있다. 초기화 되었다면 true 안되었다면 false를 반환한다.

조회한 엔티티가 프록시로 조회한건지 진짜 엔티티인지 확인하려면 클래스명을 직접 출력해보면 된다.

뒤에 javassist가 붙으면 프록시이다.

2. 즉시 로딩과 지연 로딩

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

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

ex) em.find(Member.class, "member1")는 회원 엔티티와 함께 팀 엔티티도 함께 조회한다.

설정 방법 : @ManyToOne(fetch = FetchType.EAGER)

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

ex) member.getTeam(). getName() 조회한 팀 엔티티를 실제 사용하는 시점에 조회한다.

설정 방법 : @ManyToOne(fetch = FetchType.LAZY)

즉시 로딩

쿼리 한번으로 두 엔티티를 모두 조회한다.(조인)

* nullable 설정에 따른 조인 전략

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

지연 로딩

em.find()를 호출하면 회원만 조회하고 팀은 조회하지 않는다. 대신 조회한 tam멤버변수에 프록시 객체를 넣어둔다.

이 프록시 객체는 실제 사용될 때까지 로딩을 미룬다. 그래서 지연 로딩이라 한다.

3. 지연 로딩 활용

- 애플리케이션 로직 분석

Member와 연관된 Team은 자주 사용되므로 즉시 로딩으로 설정했다.
Member와 연관된 Order는 가끔 사용되므로 지연 로딩으로 설정했다.
Order와 연관된 Product는 자주 함께 사용되므로 즉시 로딩으로 설정했다.

회원과 팀은 즉시 로딩이므로 회원 엔티티를 조회하면 팀 엔티티도 즉시 조회된다.

회원과 주문내역의 연관관계는 LAZY로 설정했다. 따라서 주문내역 엔티티는 조회해서 실제 사용될 때까지 로딩을 지연한다.

이렇게 하면 회원과 팀을 한번에 조회한다. 하지만 회원과 주문내역은 프록시로 조회한다. 따라서 SQL에 전혀 나타나지 않는다.

프록시와 컬렉션 래퍼

이제 주문 내역을 조회해보자.

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

다음으로 member.getOrders().get(0)을 호출한다면 연관된 상품도 함께 로딩된다 (FetchType.EAGER 로 설정했기 때문에)

JPA 기본 페치 전략

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

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

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

컬렉션을 하나 이상 즉시 로딩하는 것은 권장하지 않는다. 컬렉션과 조인한다는 것은 DB 테이블로 보면 일대다 조인이기 때문에 결국 데이터가 다 쪽에 있는 수만큼 증가하기 때문으로 성능이 저하될 수 있다.
컬렉션 즉시 로딩은 항상 외부 조인을 사용한다.NOT NULL 제약 조건을 걸어두면 내부 조인을 사용해도 괜찮지만 회원이 한명도 없는 팀을 내부 조인하면 조회되지 않으므로 외부 조인을 사용한다.

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

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

4. 영속성 전이 : CASCADE

특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 같이 영속 상태로 만들고 싶으면 영속성 전이 기능을 사용하면 된다.

부모 1명에 자식 2명을 저장해보자

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

영속성 전이 : 저장

이렇게 한다면 부모와 자식 엔티티를 한 번에 영속화 할 수 있다.

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

영속성 전이 : 삭제

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

CascadeType.REMOVE로 설정하고 부모 엔티티만 삭제하면 연관된 엔티티도 함께 삭제된다.

위 코드를 사용하면 외래 키 제약조건을 고려해서 자식을 먼저 삭제하고 부모를 삭제한다. 하지만 CasecadeType.REMOVE를 설정하지 않고 위 코드를 실행한다면 부모 엔티티만 삭제되므로 외래키 무결성 예외가 발생한다.

CASCADE의 종류

여러 속성도 같이 사용 가능하다.

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

5. 고아 객체

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

위 코드를 사용하면

고아 객체 제거 기능은 영속성 컨텍스트를 플러시할 때 적용되므로 플러시 시점에 DELETE SQL이 실행된다.

모든 자식 엔티티를 제거하려면 다음 코드처럼 컬렉션을 비우면 된다.

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

고아 객체 제거는 CascadeType.REMOVE를 설정한 것과 개념적으로 같다.

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

일반적으로 엔티티는 EntityManager.persist()를 통해 영속화되고 EntityManager.remove()를 통해 제거된다. 이것은 엔티티 스스로 생명주기를 관리한다는 뜻이다. 그런데 두 옵션을 모두 활성화하면 부모 엔티티를 통해서 자식의 생명주기를 관리할 수 있다.

- 순서예시

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

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

**참고**

@OneToMany, @ManyToMany는 기본이 지연 로딩이다.

'Spring > JPA' 카테고리의 다른 글

객체지향 쿼리 언어 (1) 객체지향 쿼리 소개, JPQL (0)	2023.07.16
값 타입 (0)	2023.07.16
고급 매핑 (0)	2023.07.14
다양한 연관관계 매핑 (0)	2023.07.13
연관관계매핑 기초 (0)	2023.07.13