쓰기 지연 저장소와 지연 로딩

쓰기 지연 저장소는 DB에 실제 적용하기 전까지 변경사항을 가지고 있는 장소이고

지연 로딩은 프록시를 통해 DB의 실제 정보를 가져오는 것을 미루는 것이다

 

그러므로

DB에 쓰느냐, DB에서 가지고 오느냐로 구별하면 되겠다

 

참고로 공통점은 영속성 컨텍스트를 거친다는 점이다

---

프록시 객체가 포함하는 최소한의 정보

식별자 (ID): 엔티티를 식별하기 위한 기본 키 정보
엔티티 타입 정보: 엔티티의 클래스 타입이나 인터페이스 정보
지연 로딩 로직: 실제 데이터베이스 접근을 지연시키는 로직
초기화 플래그: 프록시 객체가 초기화되었는지 여부를 추적하는 플래그

 

DB를 불러내는 방식에는 두 가지가 있는데,

그 중 em.getFind는 Entity를 찾아오는 것이고

em.getReference 를 통하였을 때 우선순위로 프록시가 호출되어 나간다

여기서 우선순위라고 표현한 이유는

영속성 컨텍스트 안에 이미 찾는 Entity가 있을 경우 실제 Entity를 반환하기 때문이다

 

그 조건으로는 프록시가 가지고 있는 정보만 불렸을 때이다

많은 예로 id만 불렀을 때는 프록시가 불려 나가고

id 이외의 것들을 불렸을 때야 비로소 실제 DB를 조회하여 가지고 온다

이 때 DB 조회는 영속성 컨텍스트를 거치게 되며, DB에서 Entity의 정보를 proxy 에 "담는다"

즉 Entity 자체를 가지고 오는 것이 아니라는 것이다

원본 Entity를 상속받아서 데이터를 가지고 있는 상태가 된 것이며

이 때의 proxy를 초기화 되었다고 말한다

 

Entity를 상속 받는 것이므로 Entity 와 proxy 는 동일하다고 할 수 없기에

== 비교시 false 가 된다

대신 instanceof 를 이용하면 true가 반환된다

 

** 참고

em.getReference 사용시 영속성 컨텍스트의 도움을 받기 때문에

준영속 상태일 때 proxy를 초기화하면 에러가 발생한다

 

테이블 연관 관계 설정할 때 proxy 사용여부를 결정할 수 있는데,

한 객체를 불러냈을 때 연관된 객체도 바로 부를 것인지를 설정하는 것으로 보면 된다

 

@ManyToOne 등 의 오른쪽에
(fetch = FetchType.LAZY) 를 적으면 proxy 가 사용되고

(fetch = FetchType.EAGER) 를 적으면 즉시 로딩이 되어 proxy가 사용되지 않는다

 

즉시로딩의 경우

연관관계가 많을수록 즉시로딩을 할 경우 DB 조회량이 늘어나므로 추천하지 않는다

 

@OneToOne, @ManyToOne 의 경우 default가 EAGER 이며

@ManyToMany, @OneToMany 의 경우 default 가 LAZY 이다

가능하면 모두 LAZY로 설정해 두는 것이 좋