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

목차

• 프록시
• 즉시 로딩과 지연 로딩
• 지연 로딩 활용
• 영속성 전이 : CASCADE
• 고아 객체
• 영속성 전이 + 고아 객체, 생명주기
• 실전 예제

프록시

프록시 기초

• em.find() vs em.**getRerence()**
• em.find() : 데이터베이스를 통해서 실제 엔티티 객체 조회
• em.getReference() : 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회
  

Member member = new Member();
member.setUsername("hello");
em.persist(member);

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

// select query 나가지 않음! 프록시객체 반환됨. Id는 이미 알고 있는 값 
Member findMember = em.getReference(Member.class, member.getId()); 

// 이 시점에 select query 나감! DB에만 있는 값을 조회하는 시점에 조회 
System.out.println("findMember.getUsername() = " + findMember.getUsername());

 

프록시 특징

• 실제 클래스를 상속 받아서 만들어짐 (하이버네이트가 내부적으로 강제로 만든 가짜 클래스)
• 실제 클래스와 겉 모양이 같음
• 사용하는 입자에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 됨 (이론상..)
• 프록시 객체는 실제 객체의 **참조(target)**을 보관
• 프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드 호출!

• 프록시 객체는 처음 사용할 대 한 번만 초기화
• 프록시 객체를 초기화 할 때, 프록스 객체가 실제 엔티티로 바뀌는 것은 아님. 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근 가능
• 프록시 객체는 원본 엔티티를 상속받음. 따라서 타입 체크시 주의해야 함( == 비교 실패, 대신 instance of 사용)
• 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해도 실제 엔티티 반환
  • cf) JPA에서의 == 비교는 영속성 컨텍스트의 한 트랜젝션 안에서 같은 객체면 true를 반환!
    • 프록시 객체 호출 시 같은 영속성 컨텍스트에 실제 엔티티 있으면 실제 엔티티 반환해줌. 이를 보장
    • 두 엔티티 모두 프록시 객체라도, 같은 영속성 컨텍스트 안에 있으면 같은 프록시 객체 반환됨!
    • 같은 영속성 컨텍스트 안에서
      (1) 프록시 객체 호출 → (2) 실제 엔티티 호출(find) 하면,
      두 번째 객체도 프록시 객체를 반환! (== 비교 참을 보장하기 위해!)
• 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하면 문제 발생 (예외 throw)
  • 하이버네이트는 org.hibernate.LazyInitalizationException 예외를 터트림
  • ex) 하나의 트랜젝션이 끝나면 영속성 컨텍스트도 초기화되는데, 그 이후에 프록시 객체를 참조하면 발생할 수 있음!

프록시 객체의 초기화

// 프록시 객체 초기화 
Member member1 = em.getReference(Member.class, "id1");
member1.getUsername();

프록시 확인

• 프록시 인스턴스의 초기화 여부 확인
• PersistenceUnitUtil.isLoaded(Object entity);
• 프록시 클래스 확인 방법
• entity.getClass().getName() 출력 (..javasist.. or HibernateProxy..)
• 프록시 강제 초기화 (Hibernate)
• org.hibernate.Hibernate.initalize(entity);
• 참고 : JPA 표준은 강제 초기화 없음
• 강제 호출 : member.getName()

즉시로딩과 지연로딩

Member를 조회할 때 Team도 함께 조회해야 할까?

→ Member 정보만 사용하는 비즈니스 로직이라면 굳이 같이 조회할 필요 없음

지연 로딩

• 지연로딩 LAZY를 사용해서 프록시로 조회
• 실제 Team을 사용하는 시점에 초기화 (DB 조회)

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE,
            generator = "MEMBER_SEQ_GENERATOR")
    private Long id;
    @Column(name = "name") 
    private String username;
    private Integer age;
 
    @ManyToOne(fetch = FetchType.LAZY)  //지연로딩
    @JoinColumn(name = "TEAM_ID")
    private Team team;
}

Member memberLazy = new Member();
em.persist(memberLazy);
em.flush();
em.clear();

memberLazy.getTeam().getName(); // 이 때 team 초기화됨 (DB 조회)

즉시로딩

• 즉시로딩 EAGER를 사용해서 함께 조회
• 즉시로딩(EAGER), Member 조회시 항상 Team도 조회
• JPA 구현체는 가능하면 조인을 사용해서 SQL 한번에 함께 조회

@Entity
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE,
            generator = "MEMBER_SEQ_GENERATOR")
    private Long id;
    @Column(name = "name") 
    private String username;
    private Integer age;
 
    @ManyToOne(fetch = FetchType.EAGER)  //즉시로딩
    @JoinColumn(name = "TEAM_ID")
    private Team team;
}

Member memberEager = new Member();
em.persist(memberEager);
em.flush();
em.clear();

 
em.find(Member.class, memberEager.getId()); // Team도 같이 초기화됨 (Join Query)

프록시와 즉시로딩 주의

• 가급적 지연 로딩만 사용(특히 실무에서)
• 즉시로딩을 적용하면 예상하지 못한 SQL이 발생
• 즉시로딩은 JPQL에서 N+1 문제를 일으킴
• @ManyToOne, @OneToOne은 기본이 즉시 로딩 → LAZY로 설정
• @OneToMany, @ManyToMany는 기본이 지연로딩
• 한번에 조회해야할 때는 fetch join 사용!

지연 로딩 활용 -이론

• Member와 Team은 자주 함께 사용 → 즉시 로딩
• Member와 Order는 가끔 사용 → 지연 로딩
• Order와 Product는 자주 함께 사용 → 즉시로딩

지연 로딩 활용 -실무

• 모든 연관관계에 지연로딩을 사용해라!
• 실무에서 즉시로딩을 사용하지 마라!
• JPQL fetch 조인이나, 엔티티 그래프 기능을 사용해라!
• 즉시 로딩은 예상치 못한 쿼리가 나간다!

영속성 전이(CASCADE)와 고아 객체

영속성 전이: CASCADE

• 특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들고 싶을 때
• 예: 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장
• 객체 저장시 객체의 연관관계도 함께 저장하고 싶을 때 사용
• 하나의 부모만이 해당 자식 객체를 관리할 때는 사용 가능. 하지만 그 자식 객체를 여러군데에서 관리하고, 연관관계가 맺어있을 때는 문제가 발생. 즉, 소유자가 하나일 때만 사용하기
  → (1) 단일 엔티티에 종속적일 때. (2) 라이프사이클이 거의 유사할 때 사용

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

주의점

• 영속성 전이는 연관관계를 매핑하는 것과 아무 관련이 없음
• 엔티티를 영속화할 대 연관된 엔티티도 함께 영속화하는 편리함을 제공할 뿐

CASCADE의 종류

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

고아 객체

• 고아 객체 제거 : 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제
• orphanRemoval = true

Parent parent = em.find(Parent.class, id);
parent.getChildren().remove(0); //자식 엔티티를 컬렉션에서 제거 -> 바로 해당 오펀 객체 DB에서 DELETE됨

고아 객체 -주의

• 참조가 제거된 엔티티는 다른 곳에서 참조하지 않는 고아 객체로 보고 삭제하는 기능
• 참조하는 곳이 하나일 때 사용해야 함!
• 특정 엔티티가 개인 소유할 때 사용
• @OneToOne, @OneToMany만 가능
• 참고 : 개념적으로 부모를 제거하면 자식은 고아가 된다. 따라서 고아 객체 제거 기능을 활성화하면, 부모를 제거할 때 자식도 함께 제거된다. 이것은 CascadeType.REMOVE처럼 동작한다.

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

• CascadeType.ALL + orphanRemoval=True
• 스스로 생명주기를 관리하는 엔티티는 em.persist()로 영속화, em.remove()로 제거
• 두 옵션을 모두 활성화하면 부모 엔티티를 통해서 자식의 생명주기를 관리할 수 있음
• 도메인 주도 설계(DDD)의 Aggregate Root개념을 구현할 때 유용
• → Aggregate Root : DB는 Aggregate Root를 통해서 접근하는 개념

 

출처 : 자바 ORM 표준 JPA 프로그래밍-기본편 (김영한), 자바 ORM 표준 JPA 프로그래밍(김영한 저)