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

[MinJunKweon]

[MinJunKweon]

끄적끄적

• 객체들은 객체 그래프로 연관된 객체를 탐색함. 하지만, DB상에 존재하기 때문에 필요할 때 가져오도록 하는 것이 효과적임.
• 필요하는 시점에 연관된 객체를 가져오기 위해 프록시를 사용함 (지연 로딩)
• 프록시 객체 초기화 : 대상 객체를 실제로 DB에서 조회해서 생성하는 과정
• 엔티티 접근방식
  • @Access(AccessType.PROPERTY) : Getter 메소드를 사용해서 접근. (식별자 외의 필드 접근 시 프록시 객체 초기화)
  • @Access(AccessType.FIELD) : 필드에 직접 접근. private 필드도 무관. (어떤 프록시 객체 초기화)
• 로딩 방식
  • 즉시 로딩(Eager Loading) : 자주 사용되는 연관객체는 초기화할 때 한번에 JOIN으로 가져오는 것이 효율적임
    • 기본적으로 LEFT OUTER JOIN을 통해 조인하지만, @JoinColumn(nullable = false) 값을 주면 INNER JOIN을 사용할 수 있음.
  • 지연 로딩(Lazy Loading) : 잘 사용되지 않는 연관객체는 사용하는 시점에 DB에서 가져오는 것이 효율적임
    • 프록시 객체가 레퍼런스로 들어가 있어서 실제로 사용되기 전까지는 실제 DB 값을 가지는 대상 객체는 초기화가 안되어있음
    • 컬렉션들도 지연 로딩을 사용할 수 있음. 하이버네이트에서 컬렉션 래퍼를 제공하기 때문에 컬렉션을 접근한다해도 전부 초기화하지 않음. 특정 1개 엘리먼트에 접근 시 DB상에서 호출된 엘리먼트만 초기화하는 방식
• 연관관계가 끊어진 객체들은 고아 객체로 판단해서 삭제하는 기능을 제공함
  • 하지만, 그냥 단순히 참조가 제거된 엔티티는 다른 곳에서 사용하지 않는다고 간주해서 삭제하기 때문에 여러 군데에서 사용하는 객체는 사용하면 안됨.
  • 부모를 제거하면 자식이 제거되기 때문에 CascadeType.REMOVE를 설정한 것과 같은 효과

[LOG-INFO]

Glossary

• 프록시 (Proxy): Entity class를 상속한 가짜 객체
  • 사용하는 입장에서는 이것이 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 된다
    • 하지만 type check 시 주의 필요
  • 프록시 여부 확인 가능 (PersistenceUnitUtil.isLoaded(Object entity))
  • Collection의 경우 Collection Wrapper 사용
• 즉시로딩 (Eager Loading): 조회되는 순간 DB에서 조회하는 옵션 (Join query 사용)
  • nullable=true: Outer Join 사용
  • nullable=false: Inner Join 사용 (단, Collection인 경우 무조건 Outer Join 사용)
• 지연로딩 (Lazy Loading): 프록시를 사용해 처음에는 DB에서 조회하지 않고 있다가, 필요한 순간 DB에서 조회하는 옵션
  • 모든 연관 관계에 지연 로딩을 사용하고, 최적화 필요한 곳만 즉시 로딩 사용하는 것 추천
• 객체 그래프 (Object Graph): 연관된 객체 사이의 그래프
• 영속성 전이(Transitive Persistency): 부모 객체가 저장/삭제 등의 변경사항이 있을 때 자식객체도 같이 저장/삭제함

  • 엄청 위험할 듯. 매우 신중히 사용 필요.

• 고아 객체(Orphan Object): 부모 Entity와 연관관계가 끊어진 Entity. 고아 객체 자동 삭제 기능을 통해 삭제됨

  • Garbage Collector 같음

  • 부모가 죽으면 자식도 같이 죽는다니 ㅠㅠ 약간 순장 같다...

[minkukjo]

끄적끄적

• JPA의 지연 로딩은 얼핏보면 편리해보이지만, 거기엔 참 함정이 많은 것 같다.
• 준영속 상태의 프록시 객체를 초기화하면 문제가 발생할 수 있음. ( 프록시 객체 초기화는 영속성 컨텍스트의 도움을 받기 때문)
• JPA는 기본적으로 연관관계의 NULL을 허용하기 때문에 외부 조인을 사용한다.
  • 저자는 외부 조인보다 내부 조인이 성능 최적화에 더 유리하다고 한다.
  • 내부 조인을 사용하기 위해서는 NULL 제약조건을 없애야하기 때문에 컬럼에 nullable=false를 주면 된다고 함.
• JPA에선 일대다 관계에선 가급적이면 외부 조인을 사용하는게 좋다고 함. ( 1:N에서 N이 없는 경우도 있으니 )
• CASCDE 옵션에 대해서도 이야기하는데, DB에서도 그렇고, 애플리케이션도 그렇고 가급적이면 이런 기능은 안쓰는게 좋은 것 같음. ( 데이터 삭제는 매우 매우 신중하게 해야하는 작업임 )
• 고아객체는 부모객체와 자식 객체의 생명 주기를 함께 가져가는 것을 의미함.
• 연관관계가 끊어진 객체는 고아 객체로 판단해서 삭제해버림.
• 이것도 좀... 위험한 듯..

궁금해서 찾아본 점

• 내부 조인과 외부 조인은 성능상 어떻게 다를까?
  • 조인의 내부 설명 : https://schatz37.tistory.com/2
  • 드라이빙 테이블과 드리븐 테이블 설명 : https://qingmi-53.tistory.com/231
  • 일반적으로 DB 조인할 때는 Nested Loop 조인을 많이 사용하는데, 이 경우 드라이빙 테이블 레코드 수 * 드리븐 테이블 레코드수 만큼 접근을 하게 된다.
  • 결국 저 룩업되는 테이블 레코드 수를 줄이는 것이 조인 성능을 최적화하는 방법인데, Outter Join의 경우 해당 데이터의 존재 유무와 관련 없이 모든 데이터를 룩업해야하기 때문에 Inner 조인보다는 룩업 대상이 많아져서 느릴 수 있음. ( 물론 옵티마이저가 최적화를 잘 해주긴 하겠지만... )

[HaeUlNam]

끄적끄적

• 지연로딩: 연관된 엔티티들이 사용되지 않는 경우 같이 조회하는 것이 비효율적이기에, 엔티티가 실제 사용될때까지 데이터베이스 조회를 지연하는 방법
  • 지연 로딩은 프록시 객체를 통해 데이터베이스 조회를 지연시킨다.
  • Hibernate는 지연 로딩을 지원하기 위해 프록시를 사용하는 방법과 바이트코드를 수정하는 두 가지 방법 제공
  • 모든 연관관계에 지연 로딩을 사용하고, 최적화가 필요한 경우 즉시 로딩으로 변경
    • SQL을 직접 사용하면 이런 유연한 최적화가 어렵다
  • e.g. @manytoone(fetch = FetchType.LAZY)
• 즉시 로딩: 엔티티를 조회할 때 연관된 엔티티도 함께 조회
  • JPA 구현체는 최적화를 위해 가능하면 조인 쿼리를 사용
  • e.g. @manytoone(fetch = FetchType.EAGER)
• 지연 로딩 With 프록시
  • 프록시 객체는 실제 객체에 대한 참조를 보관하고, 사용하는 입장에서는 진짜 객체인지/프록시 객체인지 구분하지 않고 사용하면 된다 - https://refactoring.guru/ko/design-patterns/proxy
  • 프록시 초기화는 영속성 컨텍스트의 도움을 받아야 가능. 준영속 상태의 프록시를 초기화하면 문제 발생(LazyInitializationException)
  • 접근 방식: AccessType.PROPERTY, AccessType.FIELD
  • 프록시 초기화 여부 확인: PersistneceUnitUtil.isLoaded
  • 조회한 엔티티가 Real 엔티티인지 프록시인지 확인 방법: 클래스명을 직접 출력
  • 프록시 객체 생성법
    • Hibernate 5.3부터는 Byte Buddy를 사용
    • 이전 버전은 CGLIB/Javasist
    • https://in.relation.to/2016/11/18/meet-rafael-winterhalter-and-bytebuddy/