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

 

안녕하세요. 오늘은 프록시와 즉시로딩, 지연로딩 그리고 영속성 전이와 고아 객체에 대해 알아보는 시간을 가지려 합니다. 

 

김영한님의 자바 ORM 표준 JPA 프로그래밍을 읽고 정리했습니다. 

 

프록시

엔티티를 조회할 때 연관된 엔티티들이 항상 사용되는 것은 아니다. 예를 들어 회원 엔티티를 조회할 때, 연관된 팀 엔티티가 사용되지 않을 때도 있다. 사용되지 않는 팀 엔티티를 미리 조회하는 것은 효율적이지 못하다. 

 

JPA는 이런 문제를 해결하기 위해 엔티티가 실제 사용될 때까지 데이터베이스 조회를 지연하는 방법을 제공하는데 이를 지연 로딩이라고 한다. 

쉽게 이야기하면 team.getName() 과 같이 팀 엔티티 값을 실제 사용하는 시점에 데이터베이스에서 팀 엔티티에 필요한 데이터를 조회하는 것이다. 

 

지연 로딩을 하기 위해서는 실제 엔티티 객체 대신에 데이터베이스 조회를 지연할 수 있는 가짜 객체가 필요한데 이를 프록시 객체라고 한다. 

 

프록시 기초

JPA에서 식별자를 이용해서 엔티티를 조회할 때는 em.find() 메서드를 사용한다. 

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

이렇게 엔티티를 직접 조회하면 엔티티를 사용하든 안하든 무조건 데이터베이스에서 조회하게 된다. 

 

엔티티를 지연해서 조회하고 싶을 때는 em.getReference() 메서드를 사용하면 된다. 

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

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

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

프록시 객체는 실제 객체에 대한 참조를 보관한다. 프록시 객체의 메서드를 호출하면 프록시 객체는 실제 객체의 메서드를 호출한다. 

프록시 초기화

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

 

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

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

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

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

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

 

프록시의 특징은 다음과 같다.

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

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

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

- 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해도 실제 엔티티가 반환된다. 

- 초기화는 영속성 컨텍스트의 도움을 받아야 가능하다. 따라서 준영속 상태의 프록시를 초기화하면 문제가 발생한다. 

Member member = em.gerReference(Member.class, "id1");
transaction.commit();
em.close();

member.getName(); // org.hibernate.LazyInitializationException 발생

 

프록시와 식별자

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

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

프록시 객체가 식별자 값을 조회하고 있기 때문에 식별자 값으로 조회하는 getId()를 호출해도 프록시는 초기화되지 않는다. 단 엔티티 접근 방식을 프로퍼티로 설정한 경우에만 그렇다.(@Access(AccessType.PROPERTY))

엔티티 접근 방식이 필드이면 JPA는 getId()가 id만 조회하는지 다른 필드가 들어가는지 모르기 때문이다. 

 

연관관계 설정 시에는 식별자 값만 사용하므로 프록시를 사용하면 데이터베이스 접근 횟수를 줄일 수 있다.

Member member = em.find(Member.class, "member1");
Team team = em.gerReference(Team.class, "team1"); // SQL 실행 안함
member.setTeam(team); // team 프록시 초기화하지 않고 연관관계 설정

 

프록시 확인

JPA가 제공하는 아래의 메서드를 사용하면 프록시 인스턴스의 초기화 여부를 확인할 수 있다. 아직 초기화되지 않은 프록시 인스턴스는 false를 반환한다. 

PersistenceUnitUtil.isLoaded(Object entity)

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

 

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

클래스 명 뒤에 ..javassist.. 라 되어 있는데 이것으로 프록시임을 확인할 수 있다. 

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

 

 

즉시 로딩과 지연 로딩

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

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

 

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

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

 

즉시 로딩

em.find() 하는 순간 팀도 함께 조회된다. 이때 회원과 팀 두 테이블을 조회해야 하므로 쿼리를 두 번 실행할 것처럼 보이지만 대부분의 JPA 구현체는 즉시 로딩을 최적화하기 위해 가능하면 조인 쿼리를 사용한다. 

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

 

이 조인 쿼리에서 외부 조인인 left outer join을 했는데 이는 회원 테이블의 TEAM_ID 외래 키가 null을 허용하고 있기 때문이다. 

성능 최적화를 위해 내부 조인을 사용하려면 외래 키에 not null 제약 조건을 설정해야한다. @JoinColumn에 nullable = false로 설정하면 JPA는 외부 조인 대신에 내부 조인을 사용한다. 

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

혹은 @ManyToOne에서 optional = false로 지정해도 내부 조인을 사용한다. 

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

 

지연 로딩

회원과 팀을 지연 로딩으로 설정하게 되면 em.find()를 호출하면 멤버만 조회하고 팀은 조회하지 않는다. 대신에 팀 멤버변수에는 프록시 객체를 넣어둔다. 

이 프록시 객체는 실제 사용될 때까지 데이터 로딩을 미루다가 사용하게 되면 초기화된다. 

Member member = em.find(Member.class, "member1");
Team team = member.getTeam();
team.getName();

 

아래는 차례로 em.find(member), team.getName() 호출로 실행되는 SQL이다. 

SELECT * FROM MEMBER
WHERE MEMBER_ID = 'member1';

SELECT * FROM TEAM
WHERE TEAM_ID = 'team1';

 

 

지연 로딩 활용

사내 주문 관리 시스템을 개발한다고 하자.

회원은 팀 하나에만 속할 수 있다.

회원은 여러 주문 내역을 가진다.

주문 내역은 상품 정보를 가진다. 

 

멤버와 연관된 팀은 자주 함께 사용되었다. -> 즉시 로딩

멤버와 연관된 주문은 가끔 사용되었다. -> 지연 로딩

주문과 상품은 자주 함께 사용되었다. -> 즉시 로딩

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

 

회원과 팀은 즉시 로딩으로 설정하여 회원을 조회할 때 연관된 팀도 함께 조회한다. 

반면에 회원과 주문 내역은 지연 로딩을 설정했으므로 결과를 프록시로 조회한다. 

컬렉션 래퍼

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

출력 결과를 보면 컬렉션 래퍼가 반환되었다. 

엔티티를 지연 로딩하면 프록시 객체를 사용해서 지연 로딩을 수행하지만 주문 내역과 같은 컬렉션은 컬렉션 래퍼가 지연 로딩을 처리해준다. 

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

 

주문 내역과 상품은 즉시 로딩으로 설정했기 때문에 멤버에서 주문내역을 조회하게 되면 연관된 상품 또한 함께 로딩된다. 

member.getOrders() // 컬렉션 초기화 안됨
member.getOrders().get(0) // 데이터베이스 조회해서 초기화

JPA 기본 페치 전략

@ManyToOne, @OneToOne : 즉시 로딩

@OneToMany, @ManyToMany : 지연 로딩

 

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

 

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

 

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

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

 

컬렉션과 조인한다는 것은 데이터베이스 테이블로 보면 일대다 조인이다. 일대다 조인은 결과 데이터가 다 쪽에 있는 수만큼 증가하게 된다. 만약, A 테이블을 N, M 두 테이블과 일대다 조인을 하면 SQL 실행 결과가 N 곱하기 M 이 되면서 너무 많은 데이터를 반환할 수 있고 어플리케이션 성능이 저하될 수 있다. 

따라서 2개 이상의 컬렉션을 즉시 로딩하는 것을 권장하지 않는다. 

 

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

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

 

 

영속성 전이 : CASCADE

특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶으면 영속성 전이 기능을 사용한다. JPA는 CASCADE 옵션으로 영속성 전이를 제공한다. 

 

영속성 전이를 사용하면 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장할 수 있다. 

@Entity
public class Parent {
	
    @Id @GeneratedValue
    private Long id;
    
    @OneToMany(mappedBy = "parent")
    private List<Child> children = new ArrayList<>();
}

@Entity
public class Child {
	
    @Id @GeneratedValue
    private Long id;
    
    @ManyToOne
    private Parent parent;
}

 

부모 한 명에 자식 두 명을 저장한다면 아래와 같은 코드를 생각할 것이다. 

JPA에서 엔티티를 저장할 때 연관된 모든 엔티티는 영속 상태여야 한다. 따라서 아래 코드를 보면 부모 엔티티를 영속 상태로 만들고 자식 엔티티도 각각 영속 상태로 만들었다. 

private static void saveNoCascade(EntityManager em) {
	
    Parent parent = new Parent();
    em.persist(parent);
    
    Child child1 = new Child();
    child1.setParent(parent);
    parent.getChildren().add(child1);
    em.persist(child1);
    
    Child child2 = new Child();
    child1.setParent(parent);
    parent.getChildren().add(child2);
    em.persist(child2);
}

 

영속성 전이 : 저장

영속성 전이를 활성화하는 cascade 옵션이다. 

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

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

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.PERSIST로 설정한 자식 엔티티까지 함께 영속화해서 저장한다. 

 

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

 

영속성 전이 : 삭제

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

영속성 전이는 엔티티를 삭제할 떄도 사용할 수 있다. CascadeType.REMOVE로 설정하고 다음 코드처럼 부모 엔티티를 삭제하면 연관된 자식 엔티티도 함께 삭제할 수 있다. 

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

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

 

Cascase의 종류

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

 

아래와 같이 여러 속성을 같이 사용할 수 있다. 이 또한, 실행 시 바로 영속성 전이가 일어나지 않고 플러시를 호출할 때 전이가 발생한다. 

cascade = {CascadeType.PERSIST, CascadeType.REMOVE}

 

 

고아 객체

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

 

아래 코드는 고아 객체 기능을 활성화하기 위해 orphanRemoval = true로 설정했다.

@Entity
public class Parent {
	
    @Id @GeneratedValue
    private Long id;
    
    @OneToMany(mappedBy = "parent", orphanRemoval = true)
    private List<Child> children = new ArrayList<>();
}

 

아래 코드는 컬렉션에서 첫 번째 자식을 제거했다. 고아 객체 제거 기능으로 인해 컬렉션에서 엔티티를 제거하면 데이터베이스의 데이터도 삭제된다. 이 또한 플러시 시점에 데이터베이스로 쿼리가 날아간다. 

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

모든 엔티티를 삭제하려면 컬렉션을 비우면 된다. 

parent.getChildren().clear();

 

고아 객체 제거는 참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아 객체로 보고 삭제하는 기능이다. 이 기능은 참조하는 곳에 하나일 때만 사용해야 한다. 

 

orphanRemoval은 @OneToMany나 @OneToOne에서만 사용할 수 있다. 

 

고아 객체 제거에는 하나의 기능이 더 있는데 개념적으로 접근하면 부모를 제거하면 고아가 되므로 자식도 제거된다. CascadeType.REMOVE 설정과 동일하다. 

 

 

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

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

 

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

 

자식 저장

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

자식 제거

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