8장 프록시와 연관관계 관리

이주호·2024년 12월 15일
0

[BOOK] 자바 ORM 표준 JPA 프로그래밍

목록 보기
6/15
post-thumbnail

객체는 객체그래프 탐색을 통해 연관된 객체를 탐색한다. 그러나 데이터베이스에서는 나뉘어서 저장되어 있기 때문에 연관된 객체를 마음껏 탐색하기에 어려움이 있다. 이에 JPA에서는 프록시를 통해 이 문제를 해결하고 있다.
프록시를 사용하면 연관된 객체를 처음부터 데이터베이스에서 조회하는 것이 아니라, 실제 사용하는 시점에 데이터베이스에서 조회할 수 있다. 물론, 환경상 바로 조회하는 것이 유리할 경우도 있기 때문에 JPA는 즉시 로딩과 지연 로딩 모두를 지원한다.

프록시

지연로딩

객체를 조회할 때, 연관된 객체가 필요없는 경우에도 연관된 객체까지 데이터베이스에서 조회하는 것은 효율적이지 않다. 이에 JPA에서는 엔티티가 실제 사용될 때까지 데이터베이스 조회를 지연하는 방법을 제공하는데 이를 지연로딩이라고 한다.
지연 로딩을 사용하려면 실제 엔티티 객체 대신에 데이터베이스 조회를 지연할 수있는 가짜 객체가 필요한데 이것을 프록시 객체라고 한다.

프록시 기초

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

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

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

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

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

프록시 특징

프록시 클래스는 실제 클래스를 상속 받아서 만들어지므로 실제 클래스와 겉모양이 같다.
또한 프록시 객체는 실체 객체에 대한 참조(target)을 보관한다. 그리고 프록시 객체의 메서드를 호출하면 프록시 객체는 실제 객체의 메서드를 호출한다.

프록시 객체의 초기화

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

샘플 코드


//MemberProxy 반환
Member member = em.getReference(Member.class, "id1");
member.getName();	//1. getName();
...
///

public class MemberProxy extends Member{
    
    Member target = null;   // 실제 엔티티 참조
    
    public String getName() {
        
        if (target == null) {
            //2. 초기화 요청(초기화)
            //-> 프록시 객체는 실제 엔티티가 생성되어 있지 않으면
            //  영속성 컨텍스트에 실제 엔티티 생성을 요청한다.
            
            //3. DB 조회
            //  -> 영속성 컨텍스트는 DB를 조회해서 실제 엔티티 객체를 생성한다.
            
            //4. 실제 엔티티 생성 및 참조 보관
            // -> 프록시 객체는 생성된 실제 엔티티 객체의 참조를
            //  Member target 멤버변수에 보관한다.

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

프록시와 식별자

프록시 객체로 엔티티로 조회할 때 식별자값을 파라미터로 전달하는데 프록시 객체는 이 식별자값을 보관한다. 그렇기 때문에 식별자 값을 조회하는 코드에서는 프록시 객체가 초기화되지 않는다.

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

엔티티 접근 방식을 프로퍼티로 설정한 경우에만 초기화하지 않고 필드로 설정하면 프록시 객체를 초기화한다고 한다.

  • 프로퍼티 접근 : @Access(AccessType.PROPERTY) -> 식별자 조회시 프록시 객체 초기화 x
  • 필드 접근 : @Access(AccessType.FILED) -> 식별자 조회시에도 프록시 객체 초기화
    하지만 하이버네이트 버전이 올라가면서 프록시 상태일 때, 필드/프로퍼티 접근 모두 getId()를 호출할 때 초기화 하지 않도록 변경됐다고 한다.

참고 (프록시와 식별자)

현대 하이버네이트 동작 (버전 5.x 이후)

하이버네이트 5.x 이상부터는 식별자 조회 시 프록시를 초기화하지 않는 방식으로 최적화되었습니다.
즉, 필드 접근이든 프로퍼티 접근이든 getId() 호출만으로는 프록시 초기화가 발생하지 않습니다.
이는 프록시 상태를 유지하며 필요한 경우에만 데이터베이스와 통신하도록 설계된 개선 사항입니다.
하이버네이트 최적화가 적용된 버전
하이버네이트 5.2 이상에서 이러한 최적화가 더욱 안정적으로 동작하며, 최신 버전(예: Hibernate 6.x)에서도 동일한 원칙이 유지됩니다.

프록시 확인

JPA가 제공하는 PersistenceUnitUtil.isLoaded(Object entity) 메서드를 사용하면 프록시 인스턴스의 초기화 여부를 확인할 수 있다. 아직 초기화되지 않은 프록시 인스턴스는 false를, 이미 초기화되었거나 프록시 인스턴스가 아니면 true를 반환한다. (프록시 초기화 상태를 확인하는 것은 로딩된 상태인지를 확인하기 위해 사용한다. 더 자세한 내용은 아래 참고)
직접 클래스를 확인하여 프록시임을 확인할 수도 있다. getClass().getName()을 통해 프록시 객체를 확인하면 클래스 명 뒤에 ..javassist..라고 되어있다.
JPA는 프록시 강제 초기화가 없지만 하이버네이트에서는 initialize() 메서드로 강제초기화할 수 있다.

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

JPA에서 강제 초기화하려면 member.getName()처럼 프록시의 메서드를 직접 호출하면 된다.

참고(프록시 확인)

PersistenceUnitUtil.isLoaded(Object entity) 메서드의 동작은 프록시 초기화 상태뿐만 아니라 전달된 객체가 프록시인지 아닌지도 확인할 수 있도록 설계되었습니다. 따라서 프록시 인스턴스가 아닌 경우에도 true를 반환하는 것이 정상적인 동작입니다.

이유

  1. 프록시가 아닌 객체는 이미 "로딩 완료된" 상태로 간주합니다.

    • 프록시 객체는 엔티티를 완전히 초기화하기 전, 필요한 데이터를 지연 로딩하기 위해 사용됩니다.
    • 프록시가 아닌 객체는 JPA가 데이터를 이미 완전히 로드한 상태이므로 초기화 여부를 따질 필요가 없고, 따라서 true를 반환합니다.

  2. isLoaded() 메서드의 설계 철학

    • isLoaded()는 객체가 현재 로딩된 상태인지 확인하는 메서드입니다.
    • 프록시 초기화 상태를 확인하는 것이 주요 목적이지만, 프록시가 아닌 경우 "로딩 상태"를 보장하기 위해 무조건 true를 반환합니다.

동작 예시

// em은 EntityManager
Team team = em.getReference(Team.class, "team1");
System.out.println(PersistenceUnitUtil.isLoaded(team)); // false (프록시 초기화 전)

em.find(Team.class, "team1"); 
System.out.println(PersistenceUnitUtil.isLoaded(team)); // true (프록시 초기화 후)

Team team2 = em.find(Team.class, "team2");
System.out.println(PersistenceUnitUtil.isLoaded(team2)); // true (프록시가 아님, 이미 로드된 상태)

핵심

  • 프록시 객체가 초기화되지 않은 상태: isLoaded()는 false를 반환.
  • 프록시 객체가 초기화된 상태 또는 프록시가 아닌 객체: isLoaded()는 true를 반환.

즉, 프록시가 아닌 객체는 "항상 로딩된 상태"로 간주되어 true가 반환됩니다.

추가 확인이 필요할 때

프록시 여부만 확인하고 싶다면 entity instanceof HibernateProxy를 사용해 직접 확인할 수도 있습니다.

즉시 로딩과 지연로딩

프록시 객체는 주로 연관된 엔티티를 지연 로딩할 때 사용한다. member1이 team1에 속해 있다고 해보자.

Member member = em.find(Member.class, "member1");
Team team = member.getTeam();	//객체 그래프 탐색
System.out.prinln(team.getName());	// 팀 엔티티 사용

회원 엔티티를 조회할 때 팀 엔티티를 조회하는 방법은 다음과 같이 두 가지 방법이 있다.

  • 즉시 로딩
    엔티티를 조회할 때 연관된 엔티티도 함께 조회된다. em.find(Member.class, "member1")를 호출할 때 회원 엔티티와 연관된 팀 엔티티도 함께 조회된다.
    설정 방법 : @ManyToOne(fetch = FetchType.EAGER)
  • 지연 로딩
    연관된 엔티티를 실제 사용할 때 조회한다. member.getTeam().getName()처럼 조회한 팀 엔티티를 실제 사용하는 시점에 JPA가 SQL을 호출해서 팀 엔티티를 조회한다.
    설정 방법 : @ManyToOne(fetch = FetchType.LAZY)

즉시 로딩

앞서 말한 것처럼 즉시 로딩을 사용하면 em.find(Member.class, "member1")를 호출할 때 연관된 팀 엔티티도 조회한다. 이 때 회원 테이블과 팀 테이블, 두 개의 테이블을 조회해야 하므로 쿼리를 2번 실행할 것 같지만 대부분의 JPA 구현체는 즉시 로딩을 최적화하기 위해 가능하면 조인 쿼리를 사용한다.

SELECT
	M.MEMBER_ID AS MEMBER_ID,
    M.TEAM_ID AS TEAM_ID,
    M.USERNAME AS USERNAME,
    T.TEAM_ID AS TEAM_ID
    T.NAME AS NAME
FROM
	MEMBER M LEFT OUTER JOIN TEAM T
    	ON M.TEAM_ID = T.TEAM_ID
WHERE
	M.MEMBER_ID='member1'

여기서 LEFT OUTER JOIN을 사용했는데 회원테이블에 TEAM_ID 외래 키에 NULL인 경우에 해당 조인을 사용한다. 내부 조인을 사용하면 팀에 소속되지 않은 회원/팀 모두 조회할 수 없기 때문이다.
외부 조인보다 내부 조인이 성능과 최적화에서 더 유리하다. 그래서 외래 키에 NOT NULL 제약 조건을 설정을 하면 항상 값이 있는 것을 보장하기 때문에 내부 조인만 사용해도 된다.
@JoinColumn에 nullable 속성을 false로 설정해서 내부 조인을 사용하도록 변경할 수 있다. (nullable 속성은 따로 지정하지 않으면 true가 기본값이다.) 또는 @ManyToOne에 optional 속성을 false로 설정해도 된다.

지연 로딩

지연 로딩을 사용하려면 @ManyToOne에 fetch 속성에 FetchType.LAZY로 설정하면 된다.

@Entity
public class Member {

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

//지연로딩 실행코드
Member member = em.find(Member.class, "member1");
Team team = member.getTeam(); 	// 객체 그래프 탐색. 
team.getName();	//팀 객체 실제 사용

이렇게 지연로딩을 지정한 다음 연관 객체를 탐색하면 team 멤버변수에 member에 저장된 TEAM_ID 외래키 (TEAM 식별자)만을 가진 프록시 객체를 반환한다.
-> 여기서 team 멤버변수는 식별자 id = "team1"만을 가지고 있는 프록시 객체이다.

team.getName()처럼 실제 사용되기 전까지 데이터 로딩을 미룬다. 이처럼 실제 사용될 때 데이터베이스를 조회하며 프록시 객체의 초기화를 진행한다. 즉, 식별자만 가지고 있던 프록시 객체가 실제 엔티티의 나머지 값들을 받은 대리 객체가 된다는 것이다.
실행되는 SQL을 보자

// em.find(Member.class, "member1"); 호출
SELECT * FROM MEMBER
WHERE MEMBER_ID = 'member1'

// team.getName();	//팀 객체 실제 사용
SELECT * FROM TEAM
WHERE TEAM_ID = 'team1'

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

(참고) 지연로딩

지연로딩 사용하려면 em.find()가 아니라 em.getReference()를 호출해야 한다고 하지 않았나?

@ManyToOne(fetch = FetchType.LAZY) 설정을 통해 지연 로딩(Lazy Loading)을 사용할 수 있습니다. 따라서 em.getReference()를 직접 호출하지 않아도 됩니다. 이는 JPA가 FetchType.LAZY를 해석하여 프록시 객체를 자동으로 생성해 주기 때문입니다.

정리

  • 지연 로딩(LAZY) : 연관된 엔티티를 프록시로 조회한다. 프록시를 실제 사용할 때 초기화하면서 데이터베이스를 조회한다.
  • 즉시 로딩(EAGER) : 연관된 엔티티를 즉시 조회한다. 하이버네이트는 가능하면 SQL 조인을 사용해서 한 번에 조회한다.

프록시와 컬렉션 래퍼

Member member = em.find(Member.class, "member1');
List<Order> orders = member.getOrders();
System.out.prinln("orders = " + orders.getClass().getName());
//결과 : orders = org.hibernate.collection.internal.PersistentBag

하이버네이트는 엔티티를 영속 상태로 만들 때 엔티티에 컬렉션이 있으면 컬렉션을 추적하고 관리할 목적으로 원본 컬렉션을 하이버네이트가 제공하는 내장 컬렉션으로 변경하는데 이를 컬렉션 래퍼라고 한다.
엔티티를 지연 로딩하면 프록시 객체를 사용해서 지연 로딩을 수행하지만 주문 내역 같은 컬렉션은 컬렉션 래퍼가 지연 로딩을 처리해준다.
참고로 member.getOrders()를 호출해도 컬렉션은 초기화되지 않는다. 컬렉션은 member.getOrders().get(0) 처럼 컬렉션에서 실제 데이터를 조회할 때 데이터베이스를 조회해서 초기화한다.

JPA 기본 fetch 전략

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

JPA의 기본 fetch 전략은 연관된 엔티티가 하나면 즉시 로딩을, 컬렉션이면 지연 로딩을 사용한다. 컬렉션을 로딩하는 것은 많은 비용이 들기 때문에 지연 로딩을 하는데 연관된 객체가 하나면 즉시 로딩해도 큰 문제가 발생하지 않기 때문에 그렇다.
추천하는 방법은 모든 연관관계에서 지연 로딩을 사용하고 애플리케이션 개발이 어느 정도 완료단계에 왔을 때 실제 사용하는 상황을 보고 꼭 필요한 곳에만 즉시 로딩을 사용하도록 최적화하는 것이다.

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

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

  • 컬렉션 즉시 로딩은 항상 외부조인(outer join)을 사용한다.
    내부조인 . 연관된 엔티티의 외래키가 not null이 아니라면 조회할 때 null이면 해당 정보 자체가 조회되지 않는 문제가 발생하기 때문에 outer join을 사용해서 조회한다.
    예를 들어 팀 테이블에서 회원 테이블로 일대다 관계를 조인할 때 회원이 한명도 없는 팀을 내부조인하면 팀까지 조회되지 않는 문제가 발생한다. 데이터베이스 제약조건으로 이런 상황을 막을 수없어 일대다 관계를 즉시 로딩할 때 항상 외부 조인을 사용한다.

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

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

영속성 전이: CASCADE

특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶으면 영속성 전이(transitive persistence)기능을 사용하면 된다. JPA는 CASCADE 옵션으로 영속성 전이를 제공한다. 쉽게 말해 영속성 전이를 사용하면 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장할 수 있다.
JPA에서 엔티티를 저장할 때 연관된 모든 엔티티는 영속 상태여야 한다.
cascade = CascadeType.PERSIST 옵션을 설정하면 간편하게 부모와 자식 엔티티를 한 번에 영속화할 수 있다.

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

// CASCADE 저장 코드
private static void saveWithCascade(EntityManager em) {

	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를 사용하면 엔티티를 삭제할 때도 영속성 전이를 사용할 수 있다. 이를 설정하면 부모 엔티티만 삭제하면 연관된 자식 엔티티도 함께 삭제 된다.

Parent findParent = em.find(Parent.class, 1L);
em.remove(findParent);

위 코드를 실해하면 DELETE SQL이 3번 실행하고 부모는 물론 연관된 자식도 모두 삭제된다. 삭제 순서는 외래 키 제약조건을 고려해서 자식을 먼저 삭제하고 부모를 삭제한다.
이 때, CascadeType.REMOVE를 설정하지 않고 코드를 실행하면 부모 엔티티만 삭제된다. 하지만 데이터베이스의 부모 로우를 삭제하는 순간 자식 테이블에 걸려 있는 외래 키 제약조건으로 인해, 데이터베이스에서 외래키무결성 예외가 발생한다.

고아 객체(ORPHAN)

JPA는 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제하는 기능을 제공하는데 이것을 고아 객체(ORPHAN) 제거라 한다.

@Entity
public class Parent {
    @Id @GeneratedValue
    private Long id;

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

orphanRemoval 속성을 true로 설정하여 고아객체 제거를 사용해 보자.

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

위 코드를 실행하면 다음과 같은 SQL이 실행된다.

DELETE FROM CHILD WHERE ID=?

컬렉션에서 첫 번째 자식 엔티티를 제거하면 데이터베이스에도 데이터가 삭제된다. 고아 객체 제거 기능은 영속성 컨텍스트를 플러시할 때 적용되므로 플러시 시점에 DELETE SQL이 실행된다.
고아 객체 제거는 참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아 객체로 보고 삭제하는 기능이다. 그러므로 이 기능은 참조하는 곳이 하나일 때만 사용해야 한다.
또 고아 객체 제거에는 기능이 하나 더 있는데 부모 객체를 제거하면 개념적으로 자식 객체는 고아가 된다. 따라서 부모를 제거하면 자식도 같이 제거된다. 이는 CascadeType.REMOVE를 설정하는 것과 같다.

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

CascadeType.ALL + orphanRemoval = true를 동시에 설정하면 부모 엔티티를 통해서 자식의 생명주기를 관리할 수 있다.
즉, 자식을 저장하려면 부모에 등록만 하면된다.(CASCADE)

Parent parent = em.find(Parent.class, id);
parent.addChild(child1);

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

Parent parent = em.find(Parent.class, id);
parent.getChildren().remove(removeObject);

참조 : [자바 ORM 표준 JPA 프로그래밍]

profile
이주호
코드 위에서 춤추고 싶어요
이전 포스트

7장 고급 매핑

다음 포스트

9장 값 타입

0개의 댓글