Jpa기본 08. 프록시와 연관관계 관리(인프런 + 자바 ORM 표준 JPA 프로그래밍)

포스팅 개요

1. 포스팅 개요
2. 본론
       2-1. 프록시
       2-2. 즉시 로딩과 지연 로딩
       2-3. 지연 로딩 활용
       2-4. 영속성 전이:CASCADE
       2-5. 고아 객체
       2-6. 영속성 전이 + 고아 객체, 생명주기
3. 요약

1. 포스팅 개요

해당 포스팅은 인프런에서 영한님의 JPA기본 강의에서 프록시와 연관관계 관리 파트와 해당 파트에 맞는 책의 챕터를 보고 학습한 내용을 요약 및 정리하는 포스팅입니다.

2. 본론

2-1. 프록시

엔티티를 조회할 때 연관된 엔티티들이 항상 사용되는 것은 아닙니다.
회원 엔티티를 조회할 때 연관된 팀 앤티티는 비즈니스 로직에 따라 사용될 때도 있지만, 그렇지 않을 때도 있습니다.

예시를 살펴보겠습니다.

@Entity // 엔티티
public class Member extends BaseEntity {

    @Id
    private String username;

    @ManyToOne
    private Team team;

    public Team getTeam() {
        return team;
    }

    public String getUsername() {
        return username;
    }

    public Member(String username) {
        this.username = username;
    }

    public void setTeam(Team team) {
        this.team = team;
    }

    public Member() {
    }
}

@Entity
public class Team extends BaseEntity {

    @Id
    private String name;

    public String getName() {
        return name;
    }

    public Team(String name) {
        this.name = name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Team() {
    }
}

    public static void printUserAndTeam(Member member) {
        Team team = member.getTeam();
        System.out.println("회원 이름 : " + member.getUsername());
        System.out.println("소속팀 : " + team.getName());
    }

    public static void printUser(Member member) {
        System.out.println("회원 이름 : " + member.getUsername());
    }

바로 위의 printUserAndTeam() 메서드는 memberId로 회원 엔티티를 찾아서 회원은 물론이고 회원과 연관된 팀의 이름도 출력합니다.

반면에 printUser() 메서드는 회원 엔티티만 출력하는 데 사용하고 회원과 연관된 팀 엔티티는 전혀 사용하지 않습니다.

printUser() 메서드는 회원 엔티티만 사용하므로 em.find()로 회원 엔티티를 조회할 때 회원과 연관된 팀 엔티티(Member.team)까지 데이터베이스에서 함께 조회해 두는 것은 효율적이지 않습니다.

Member member = new Member("member1");
Team team = new Team("team1");
member.setTeam(team);

em.persist(team);
em.persist(member);

em.flush();
em.clear();

Member findMember = em.find(Member.class, member.getUsername());
printUser(findMember);

tx.commit();

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

team.getName()처럼 팀 엔티티의 값을 실제 사용하는 시점에 데이터베이스에서 팀 엔티티에 필요한 데이터를 조회하는 것입니다.

이 방법을 사용하면 printUser() 메서드는 회원 데이터만 데이터베이스에서 조회해도 됩니다.

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

참고

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

참고 위의 코드에 대한 실행 결과

Member member = new Member("member1");
Team team = new Team("team1");
member.setTeam(team);

em.persist(team);
em.persist(member);

em.flush();
em.clear();

Member findMember = em.find(Member.class, member.getUsername());
printUser(findMember);


tx.commit();

printUser()를 사용했는데, member에 대해서만 select 쿼리를 날릴 걸 예상했겠지만, team까지 같이 조회해버렸습니다.

왜 meber와 팀을 함께 조회하게 되는지, 왜 outer 조인을 사용하게 되는지 앞으로 나오게 될 것입니다. ^^

프록시 기초

JPA에서 식별자로 엔티티 하나를 조회할 때는 EntityManager.find()를 사용합니다. (em.find())

이 메서드는 영속성 컨텍스트에 엔티티가 없으면 데이터베이스를 조회합니다.

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

이렇게 엔티티를 직접 조회하면 조회한 엔티티를 실제 사용하든 사용하지 않든 데이터베이스를 조회하게 됩니다.
엔티티를 실제 사용하는 시점까지 데이터베이스 조회를 미루고 싶으면 EntityManager.getReference() 메서드를 사용하면 됩니다.

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

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

지금부터 프록시에 대해 알아봅시다.

프록시의 특징

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

위 그림을 보면 프록시 객체는 실제 객체에 대한 참조(targer)를 보관합니다.
프록시 객체의 메서드를 호출하면 프록시 객체는 실제 객체의 메서드를 호출합니다.

프록시 객체의 초기화

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

다음은 예시입니다.

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

위와 같이 코드가 실행될 때 프록시 클래스의 동작은 다음과 같은 방식으로 동작할 것을 예상할 수 있습니다.

class MemberProxy extends Member {

  Member target = null; // 실제 엔티티 참조

  public String getName() {

      if(target == null) {

        // 2. 초기화 요청
        // 3. DB 조회
        // 4. 실제 엔티티 생성 및 참조 보관
        this.target = ...;
      }

      // 5. target.getName();
      return target.getName();
  }
}

이처럼 코드와 그림을 통해서 프록시의 초기화 과정을 살펴보겠습니다.

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

프록시의 특징

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

Member member = new Member("member1");
Team team = new Team("team1");
member.setTeam(team);

em.persist(team);
em.persist(member);

em.flush();
em.clear();

Member findMember = em.find(Member.class, member.getUsername());
em.detach(findMember);

em.getReference(Member.class, member.getUsername());

준영속 상태와 초기화

• 준영속 상태와 초기화에 관견된 코드는 다음과 같습니다.

// MemberProxy 반환
Member member = em.getReference(Member.class, "id1");
transaction.commit();
em.close(); // 영속성 컨텍스트 종료

member.getName(); // 준영속 상태 초기화 시도  // org.hibernate.LazyInitializationException 예외 발생

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

그런데...

제가 이걸 해봤습니다만, 무슨 일인지 모르겠지만 위에서 발생한다는 예외가 나오지 않습니다...

Member member = new Member("member1");
Team team = new Team("team1");
member.setTeam(team);

em.persist(team);
em.persist(member);

em.flush();
em.clear();

Member findMember = em.getReference(Member.class, member.getUsername());
System.out.println("findMember.getClass() = " + findMember.getClass());
tx.commit();

em.close();
System.out.println("findMember.getUsername() = " + findMember.getUsername());

이처럼 프록시가 호출되고, 커밋, 엔티티매니저를 닫았음에도 불구하고, 예외가 발생하지 않습니다...ㅎ 참고로 쥐피티도 모르는 것 같습니다.

다시 코드르 수정해보겠습니다.

지금 em.getReference에서 식별자로 member.getUsername() 을 파라미터로 넘겼고, 영속성 컨텍스트를 비우고, LazyInitializationException 예외를 발생시키려 해봤지만, 발생하지 않은 이유는 이미 식별자인 username의 값을 프록시 객체가 가지고 있기 때문에 발생하지 않았습니다.

그럼 식별자가 아닌 team을 호출해보도록 하겠습니다.
위의 코드를 다음처럼 수정해주세요^^

Member findMember = em.getReference(Member.class, member.getUsername());
System.out.println("findMember.getClass() = " + findMember.getClass());
em.clear();

System.out.println("findMember.getTeam() = " + findMember.getTeam());

그림 위의 코드의 아래 5줄을 바로 위의 코드로 변경해주시면 됩니다.
그리고 실행 해보면 다음처럼 예외가 발생합니다.

식별자가 아닌 다른 메서드(혹은 값)를 호출해야 했습니다.

참고

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

(아마 하이버네이트 버전업으로 패치된 거 같기도 합니다..)

프록시와 식별자

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

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

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

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

프록시는 다음 코드처럼 연관관계를 설정할 때 유용하게 사용할 수 있습니다.

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

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

프록시 확인

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

Member member = new Member("member1");
Team team = new Team("team1");
member.setTeam(team);

em.persist(team);
em.persist(member);

em.flush();
em.clear();

Member findMember = em.getReference(Member.class, member.getUsername());
System.out.println("findMember.getClass() = " + findMember.getClass());

System.out.println("====식별자만 조회함==== 초기화 전이므로 false 나와야 함===== ");
System.out.println("isLoaded : "+emf.getPersistenceUnitUtil().isLoaded(findMember));

System.out.println("findMember.getTeam() = " + findMember.getTeam());
System.out.println("==== findMember.getTeam()을 통해서 초기화 했으므로 아래에는 true가 나와야 함.===== ");
System.out.println("isLoaded : "+emf.getPersistenceUnitUtil().isLoaded(findMember));

tx.commit();

다음은 결과 입니다.

조회한 엔티티가 진짜 엔티티인지 확인하려면 클래스명을 직접 출력해보면 됩니다.
위의 예시에서도 getClass를 통해서 보면 클래스 명 뒤에 ..HibernateProxy..(책에서는 ..javassist..)라 되어있는데 이것으로 프록시인 것을 확인할 수 있습니다.
프록시를 생성하는 라이브러리에 따라 출력 결과는 달라질 수 있습니다.

참고

프록시 강제 초기화

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

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

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

Member member = new Member("member1");
Team team = new Team("team1");
member.setTeam(team);

em.persist(team);
em.persist(member);

em.flush();
em.clear();

Member findMember = em.getReference(Member.class, member.getUsername());
Hibernate.initialize(findMember);

System.out.println("프록시 강제 초기화 이후 초기화되었는지 아래에서 확인");
System.out.println(emf.getPersistenceUnitUtil().isLoaded(findMember));

tx.commit();

다음은 결과입니다.

2-2. 즉시 로딩과 지연 로딩

프록시 객체는 주로 연관된 엔티티를 지연 로딩할 때 사용합니다.
회원 엔티티를 조회할 때 연관된 팀 엔티티도 함꼐 데이터베이스에서 조회하는 것이 좋을까요?
아니면 회원 엔티티만 조회해 두고 팀 엔티티는 실제 사용하는 시점에 데이터베이스에서 조회하는 것이 좋을까요?
당연히 후자입니다.

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

• 즉시 로딩

  • 엔티티를 조회할 때 연관된 엔티티도 함께 조회합니다.
  • 예) em.find(Member.class, "member1")를 호출할 때 회원 엔티티와 연관된 팀 엔티티도 함께 조회합니다.
  • 설정 방법: @ManyToOne(fetch = FetchType.EAGER)

• 지연 로딩

  • 연관된 엔티티를 실제 사용할 때 조회합니다.
  • 예) member.getTeam().getName()처럼 조회한 팀 엔티티를 실제 사용하는 시점에 JPA가 SQL을 호출해서 팀 엔티티를 조횝합니다.
  • 설정 방법: @ManyToOne(fetch = FetchType.LAZY)

즉시 로딩

즉시 로딩(EATER LOADING)을 사용하려면 @ManyToOne의 fetch 속성을 FetchType.EAGER로 지정해야합니다.

다음은 즉시 로딩 예시입니다.

@Entity // 엔티티
public class Member {

    @Id
    private String id;


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

    private String name;

    //... getter, setter
}

@Entity
public class Team {

    @Id
    private String id;

    private String name;

    @OneToMany(mappedBy = "team")
    List<Member> members = new ArrayList<>();

    // ...getter, setter
}

즉시 실행 코드입니다.

 Member member = new Member("member1");
Team team = new Team("team1");
member.setTeam(team);


em.persist(team);
em.persist(member);


em.flush();
em.clear();

Member findMember = em.find(Member.class, "member1");
System.out.println("즉시 로딩으로 인해 team 조회 안했음에도 불구하고 join해서 가져옴.");
System.out.println("즉시 로딩으로 인해 team 조회 안했음에도 불구하고 join해서 가져옴.");
Team team = member.getTeam(); // 객체 그래프 탐색

회원과 팀을 즉시 로딩으로 설정했습니다. 따라서 위의 예제처럼 em.find(Member.class, "member1")로 회원을 조회하는 순간 팀도 함께 조회했습니다.

이 때 회원과 팀 두 테이블을 조회해야 하므로 쿼리를 2번 실행할 것 같지만, 대부분의 JPA 구현체는 즉시 로딩을 최적화하기 위해 가능하면 조인 쿼리를 사용합니다.

여기서는 회원과 팀을 조인해서 쿼리 한 번으로 두 엔티티를 모두 조회합니다.

이와 같이 실행되는 SQL을 보면 회원과 팀을 조인해서 쿼리 한 번으로 조회한 것을 알 수 있습니다.
이후 member.getTeam()을 호출하면 이미 로딩된 팀1 엔티티를 반환합니다.

참고

NULL 제약 조건과 JPA 조인 전략
위의 SQL에서 보았던 즉시 로딩 실행 SQL에서 JPA가 내부 조인(INNER JOIN)이 아닌 외부 조인(LEFT OUTER JOIN)을 사용한 것을 봐야하는데, 회원 테이블에 있는 TEAM_ID 외래 키는 NULL 값을 허용하고 있습니다. 따라서 팀에 소속되지 않은 회원이 있을 가능성이 있습니다. 팀에 소속하지 않은 회원과 팀을 내부 조인하면 팀은 물론이고 회원 데이터도 조회할 수 없습니다.

JPA는 이런 상황을 고려해서 외부 조인을 사용합니다.
하지만 외부 조인보다 내부 조인이 성능과 최적화에서 더 유리합니다.
그럼 내부 조인을 사용하려면 어떻게 해야 할까요?
외래 키에 NOT NULL 제약 조건을 설정하면 값이 있는 것을 보장합니다.
따라서 이때는 내부 조인만 사용해도 됩니다.

JPA에게도 이런 사실을 알려줘야하는데, 다음 코드처럼 @JoinColumn에 nullable = false를 설정해서 이 외래 키는 NULL 값을 허용하지 않는다고 알려주면 JPA는 외부 조인 대신에 내부 조인을 사용합니다.

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

nullable 설정에 따른 조인 전략

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

또는 다음처럼 @ManyToOen.optional = false로 설정해도 내부 조인을 사용합니다.

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

정리하자면 JPA는 선택적 관계면 외부 조인을 사용하고, 필수 관계면 내부 조인을 사용합니다.

※ option에 대한 부분은 밑에서 나옵니다.

지연 로딩

지연 로딩(LAZY LOADING)을 사용하려면 @ManyToOne의 fetch 속성을 FetchType.LAZY로 지정합니다.

다음은 지연로딩 예시입니다.

즉시 로딩의 Member에서 team 부분의 FetchType을 LAZY로 바꿔주면 됩니다.

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

다음은 사용예시입니다.

Member member = new Member("member1");
Team team = new Team("team1");
member.setTeam(team);


em.persist(team);
em.persist(member);


em.flush();
em.clear();

Member findMember = em.find(Member.class, "member1");
System.out.println("지연 로딩으로 인해 다음 다음 코드에서 team을 join해서 가져옴.");
System.out.println("지연 로딩으로 인해 다음 다음 코드에서 team을 join해서 가져옴.");

Team findTeamByMember = findMember.getTeam(); // 프록시를 가져옴.
findTeamByMember.getId();
System.out.println("식별자를 가져오는 getId() 메서드를 사용해도 실제 객체 반환하지 않음, 즉 프록시를 반환한 것..");
System.out.println("===실제 사용되는 시점(단 식별자 외 다른 필드를 가져와야 함.===");
findTeamByMember.getName();

LAZY로 변경해준 부분을 보면 회원과 팀을 지연 로딩으로 설정했습니다.

이후 사용 코드에서 em.find(Member.class, "member1")을 호출하면 회원만 조회하고 팀은 조회하지 않습니다.

다음 그림과 같이 조회한 회원의 team 멤버변수에 프록시 객체를 넣어둡니다.

여기서 반환된 팀 객체는 프록시 객체입니다.
이 프록시 객체는 실제 사용될 떄까지 데이터 로딩을 미룹니다. 그래서 지연 로딩이라고 합니다.

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

참고

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

즉시 로딩, 지연 로딩 정리

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

대부분의 애플리케이션 로직에서 회원과 팀 엔티티를 같이 사용한다면 SQL 조인을 사용해서 회원과 팀 엔티티를 한 번에 조회하는 것이 더 효율적입니다.
결국 연관된 엔티티를 즉시 로딩하는 것이 좋은지 실제 사용할 때까지 지연해서 로딩하는 것이 좋은지는 상황에 따라 다릅니다.

간단하게 정리하면 다음과 같습니다.

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

2-3. 지연 로딩 활용

※주의 : 해당 예시는 이론상의 얘기입니다. 실무에서는 그냥 LAZY로 바르면 된다고 하셨습니다.

다음과 같은 사내 주문 관리 시스템을 개발한다고 가정했을 때

• 회원은 팀 하나에만 소속할 수 있습니다.(N:1)
• 회원은 여러 주문 내역을 가집니다.(1:N)
• 주문내역은 상품정보를 가집니다.(N:1)

로직은 다음과 같습니다.

• Member와 연관된 Team은 자주 함께 사용되었습니다. 그래서 Member와 Team은 즉시 로딩으로 설정했습니다.
• Member와 연관된 Order는 가끔 사용되었습니다. 그래서 Member와 Order는 지연 로딩으로 설정했습니다.
• Order와 연관된 Product는 자주 함께 사용되었습니다. 그래서 Order와 Product는 즉시 로딩으로 설정했습니다.

@Entity
public class Member {

    @Id
    private String id;
    private String username;
    private Integer age;

    @ManyToOne(fetch = FetchType.EAGER)
    private Team team;

    @OneToMany(mappedBy = "member", fetch = FetchType.LAZY)
    private List<Order> orders;

    // ... Getter Setter
}

위의 코드는 다음과 같습니다.

• 회원과 팀의 연관관계를 FetchType.EAGER로 설정했습니다.

• 따라서 회원 엔티티를 조회하면 연관된 팀 엔티티도 즉시 조회됩니다.

• 회원과 주문내역의 연과관계를 FetchType.LAZY로 설정했습니다.

• 따라서 회원 엔티티를 조회하면 연관된 주문내역 엔티티는 프록시로 조회해서 실제 사용될 때까지 로딩을 지연합니다.

• 회원 엔티티를 조회하면 다음 그림과 같이 엔티티를 로딩합니다.

회원과 팀은 즉시 로딩(FetchType.EAGER)로 설정했습니다.
따라서 회원을 조회할 떄 연관된 teamA도 함께 조회합니다.

Member member = new Member();
member.setId("member1");

em.persist(member);

em.flush();
em.clear();

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

위와 같은 코드가 있을 때,
실행 결과는 다음과 같습니다.

위의 Member에서 회원과 팀은 FetchType.EAGER로 설정했으므로 하이버네이트느 조인 쿼리를 만들어 회원과 팀을 한 번에 조회합니다.

회원과 주문내역은 FetchType.LAZY로 설정했으므로 결과를 프록시로 조회합니다.
따라서 위의 쿼리 결과에서 주문내역에 대한 부분은 나타나지 않습니다.

회원을 조회한 후에 member.getTeam()을 호출하면 이미 로딩된 팀 엔티티를 반환합니다.

프록시와 컬렉션 래퍼

위의 그림을 보면 즉시로딩한 teamA는 실선으로 표현했고, 지연로딩한 주문내역은 점선으로 표현했습니다.
이처럼 지연 로딩으로 설정하면 실제 엔티티 대신에 프록시 객체를 사용합니다.
프록시 객체는 실제 자신이 사용될 때까지 데이터베이스를 조회하지 않습니다.

주문 내역을 조회해보겠습니다.

Member member = new Member();
member.setId("member1");

em.persist(member);

em.flush();
em.clear();

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

List<Order> orders = findMember.getOrders();
System.out.println("orders = "+ orders.getClass());
System.out.println("orders = "+ orders.getClass().getName());

tx.commit();

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

출력결과는 컬렉션 래퍼인 org.hibernate.collection.internal.PersistentBag이 반환된 것을 알 수 있습니다.

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

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

다음 그림을 보면 주문내역과 상품의 로딩 방법을 FetchType.EAGER로 설정했습니다.
따라서 지연 로딩 상태인 주문내역을 초기화할 때 연관된 상품도 함께 로딩됩니다.

JPA 기본 페치 전략

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

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

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

그러나 거두절미하고 추천하는 방법은 모든 연과관계에 지연 로딩을 사용하는 것입니다.

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

참고로 SQL을 직접 사용하면 이런 유연한 최적화가 어렵습니다.
예를 들어 SQL로 각각의 테이블을 조회해서 처리하다가 조인으로 한 번에 조회하도록 변경하려면 많은 SQL과 애플리케이션 코드를 수정해야 합니다.

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

컬렉션에 FetchType.EAGER 사용시 주의할 점은 다음과 같습니다.

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

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

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

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

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

• @ManyToOne, @OneToOne

  • (optional = false) : 내부 조인
  • (optional = true) : 외부 조인

• @OneToMany, @ManyToMany

  • (optional = false) : 외부 조인
  • (optional = true) : 외부 조인

참고로 option에 대한 내용은 chatGPT한테 물어본 결과 not null 제약조건과 관련 있습니다.

2-4. 영속성 전이:CASCADE

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

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

코드들을 보겠습니다.

@Entity
public class Parent {

  @Id @GenerateValue
  private Long id;

  @OneToMany(mappedBy = "parent")
  private List<Child> children = new ArrayList<>();
  ...
}

@Entity
public class Child {

  @Id @GenerateValue
  private Long id;

  @ManyToOne
  private Parent parent;
  ...
}

위와 코드가 있을 때, 부모 엔티티가 여러 자식 엔티티를 가지고 있다고 가정해봅시다.

만약 부모 1명에 자식 2명을 저장한다면 다음과 같은 코드를 작성할 것입니다.

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(child2); // 부모 -> 자식
em.persist(child2);

JPA에서 엔티티를 저장할 떄 연관된 모든 엔티티는 영속 상태여야합니다.
이처럼 부모 엔티티를 영속 상태로 만들고 자식 엔티티도 각각 영속 상태로 만듭니다.
이럴 떄 영속성 전이를 사용하면 부모만 영속 상태로 만들면 연관된 자식까지 한 번에 영속 상태로 만들 수 있습니다.

영속성 전이: 저장

영속성 전이를 활성화하는 CASCADE 옵션을 적용해보면,

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

부모를 영속화할 때 연관된 자식들도 함께 영속화하라고 cascade = CascadeType.PERSIST 옵션을 설정했습니다.
이 옵션을 적용하면 다음 코드처럼 간편하게 부모와 자식 엔티티를 한번에 영속화할 수 있습니다.

Parent parent = new Parent();

Child child1 = new Child();
Child child2 = new Child();
parent.addChild(child1);
parent.addChild(child2);

em.persist(parent);

참고로 Parent의 addChild()는 연관관계 메서드로 다음과 같습니다.

public void addChild(Child child) {
    childList.add(child);
    child.setParent(this);
}

부모만 영속화하면 CascadeType.PERSIST로 설정한 자식 엔티티까지 함께 영속화해서 저장합니다.

다음은 데이터베이스에 입력된 데이터입니다.

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

그래서 예시 코드를 보면 양방향 연관관계를 추가한 다음 영속 상태로 만든 것을 확인할 수 있습니다.

영속성 전이: 삭제

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

Parent findParent = em.find(Parent.class, 1L);
Child findChild1 = em.find(Child.class, 2L);
Child findChild2 = em.find(Child.class, 3L);

em.remove(findParent);
em.remove(findChild1);
em.remove(findChild2);

영속성 전이는 엔티티를 삭제할 때도 사용할 수 있습니다.

CascadeType.REMOVE로 설정하고 다음 코드처럼 부모 엔티티만 삭제하면 연관된 자식 엔티티도 함꼐 삭제 됩니다.

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

코드를 실행하면 DELETE SQL을 3번 실행하고 부모는 물론 연관된 자식도 모두 삭제 됩니다.

@Entity
public class Parent {

  ...
  @OneToMany(mappedBy = "parent", cascade = { CascadeType.REMOVE, CascadeType.PERSIST} ) // REMOVE 추가
  private List<Child> childList = new ArrayList<>();
  ...

}

Parent parent = new Parent();

Child child1 = new Child();
Child child2 = new Child();
parent.addChild(child1);
parent.addChild(child2);

em.persist(parent);

em.flush();
em.clear();

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

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

만약 CascadeType.REMOVE를 설정하지 않고 이 코드를 실행하면 어떻게 될까요?
그러면 부모 엔티티만 삭제됩니다.

하지만 데이터베이스의 부모 로우를 삭제하는 순간 자식 테이블에 걸려 있는 외래 키 제약조건으로 인해 데이터베이스에서 외캐리 무결성 예외가 발생합니다.

@OneToMany(mappedBy = "parent", cascade = CascadeType.PERSIST ) // 위의 코드에서 REMOVE 제거
private List<Child> childList = new ArrayList<>();

CASCADE 종류

다음은 CascadeType의 종류입니다.

중괄호를 이용해서 여러 속성을 같이 사용할 수 있습니다.
(자바의 애너테이션 사용법을 아시면 됩니다.)

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

2-5. 고아 객체

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

먼저 고아 객체 제거 기능을 설정해보도록 하겠습니다.
Parent 클래스에서 다음과 같이 설정하면 됩니다.

@OneToMany(mappedBy = "parent", cascade = CascadeType.PERSIST ,orphanRemoval = true )
private List<Child> childList = new ArrayList<>();

위의 코드에서 고아 객체 제거 기능을 활성화하기 위해서 orphanRemoval = true로 설정했습니다.

이제 컬렉션에서 제거한 엔티티는 자동으로 삭제됩니다.

다음은 사용코드입니다.

Parent parent = new Parent();

Child child1 = new Child();
Child child2 = new Child();
parent.addChild(child1);
parent.addChild(child2);

em.persist(parent);
em.persist(child1);
em.persist(child2);

em.flush();
em.clear();

Parent findParent = em.find(Parent.class, 1L);
findParent.getChildList().remove(0); // 자식 엔티티를 컬렉션에서 제거

tx.commit();

결과 입니다.

(책에서는 cascade = CascadeType.PERSIST 없이 되어있는데, 추가를 해줘야 예상대로 잘 동작합니다. 여하튼...)

사용 코드를 보면 컬렉션에서 첫 번째 자식을 제거했습니다.
orphanRemoval = true 옵션으로 인해서 컬렉션에서 엔티티를 제거하면 데이터베이스의 데이터도 삭제됩니다.

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

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

findParent.getChildList().clear(); // 자식 엔티티를 컬렉션에 모두 제거

두 개의 delete 쿼리가 나가는 것을 확인할 수 있습니다.

고아 객체 정리

• 참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아 객체로 보고 삭제하는 기능입니다.
• 이 기능은 참조하는 곳이 하나일 때만 사용해야 합니다.
• 특정 엔티티가 개인 소유하는 엔티티에만 이 기능을 적용해야 합니다.
• 삭제한 엔티티를 다른 곳에서도 참조한다면 문제가 발생할 수 있습니다.
• 이러한 이유로 orphanRemovel은 @OneToOne, @OneToMany에만 사용할 수 있습니다.
• 고아 객체 제거에는 기능이 하나 더 있는데, 개념적으로 볼 때 부모를 제거하면 자식은 고아가 됩니다. 따라서 부모를 제거하면 자식도 같이 제거됩니다. 이는 CascadeType.REMOVE를 설정한 것과 같습니다.

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

CascadeType.ALL + orphanRemoval = true를 동시에 사용하면 어떻게 될까요?
일반적으로 엔티티는 EntityManager.persist()를 통해 영속화되고 EntityManager.remove()를 통해 제거됩니다.
이는 엔티티 스스로 생명주기를 관리한다는 뜻입니다.
그런데 두 옵션을 모두 활성화하면 부모 엔티티를 통해서 자식의 생명주기를 관리할 수 있습니다.

예를 들면 다음과 같습니다.
자식을 저장하려면 부모에 등록만 하면 됩니다.(CASCADE)

Parent parent = em.find(Parent.class, parentId);
parent.addChild(child);

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

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

참고

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

3. 요약

지금까지 프록시의 동작 원리에 대해 알아보고 즉시 로딩과 지연 로딩에 관해서도 알아보앗습니다. 그리고 영속성 전이와 고아 객체 제거 기능도 알아보았습니다.

• JPA 구현체들은 객체 그래프를 마음껏 탐색할 수 있도록 지원하는데 이때 프록시 기술을 사용합니다.
• 객체를 조회할 때 연관된 객체를 즉시 로딩하는 방법을 즉시 로딩이라 하고, 연관된 객체를 지연해서 로딩하는 방법을 지연 로딩이라고 합니다.
• 객체를 저장하거나 삭제할 때 연관된 객체도 함께 저장하거나 삭제할 수 있는데 이것을 영속성 전이라고합니다.
• 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제하려면 고아 객체 제거 기능을 사용하면 됩니다.

다음 포스팅은 09 값 타입에 대한 포스팅입니다.