JPA에서 식별자로 엔티티를 조회할 때는 EntityManager.find()
를 사용한다. 이 메소드는 영속성 컨텍스트에 엔티티가 없으면 데이터베이스를 조회한다. 즉 조회한 엔티티를 실제 사용하든, 사용하지 않든 데이터베이스를 조회한다.
엔티티를 실제 사용하는 시점까지 데이터베이스 조회를 미루고 싶으면 EntityManager.getReference()
를 사용하면 된다. 이 메소드를 호출할 때 JPA는 데이터베이스를 조회하지 않고 실제 엔티티 객체도 생성하지 않는다. 대신 데이터베이스 접근을 위임한 프록시 객체를 반환한다.
프록시 클래스는 실제 클래스를 상속 받아서 만들어진다. 그리고 프록시 객체는 실제 객체에 대한 참조(target)를 보관하고, 프록시 객체의 메소드를 호출하면 프록시 객체는 실제 객체의 메소드를 호출한다.
프록시 객체는 member.getName()
처럼 실제 사용될 때 데이터베이스를 조회해서 실제 엔티티 객체를 생성해서 프록시 객체의 target 변수에 보관하는데, 이를 프록시 객체의 초기화라 한다.
Member member = em.getReference(Member.class, "id1"); //target에 아직 값이 없다
member.getName(); //target에 실제 엔티티 객체가 보관된다
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();
}
}
프록시 객체의 초기화 과정은 다음과 같다.
프록시 객체에 member.getName()
을 호출한다.
프록시 객체는 실제 엔티티가 생성되어 있지 않으면, 영속성 컨텍스트에 실제 엔티티 객체를 요청한다. 그리고 이것을 초기화라고 한다.
영속성 컨텍스트는 데이터베이스를 조회해서 실제 엔티티 객체를 생성한다.
프록시 객체를 생성된 실제 엔티티 객체의 참조를 target
변수에 보관한다.
프록시 객체는 실제 엔티티 객체의 getName()
을 호출하고 결과를 반환한다.
엔티티를 프록시로 조회할 때 식별자 값을 파라미터로 전달하는데, 프록시 객체는 이 식별자 값을 보관한다. 따라서 식별자 값을 조회하는 team.getId()
를 호출해도 프록시를 초기화하지 않는다.
Team team = em.getReference(Team.class, "team1"); //프록시 객체인 team은 식별자("team1")를 보관한다.
team.getId(); //초기화되지 않는다.
Member member = new Member();
member.setName("member1");
em.persist(member);
//영속성 컨텍스트 비우기
em.flush();
em.clear();
Member refMember = em.getReference(Member.class, member.getId());
//이때 실제 데이터베이스에 select 쿼리가 나가고, 프록시 객체를 초기화한다.
System.out.println(refMember.getName());
//이때는 실제 데이터베이스를 조회하지 않고(select 쿼리 X), 프록시 객체를 통해 엔티티에 접근한다.
System.out.println(refMember.getName());
프록시를 초기화한다고 해서 프록시 객체 자체가 바뀌는 것이 아니라, 프록시 객체의 target 변수에 값이 채워지는 것이다. 그리고 프록시 객체가 초기화되면 프록시 객체를 통해 실제 객체에 접근할 수 있다.
Member refMember = em.getReference(Member.class, member.getId());
System.out.println("초기화 전 = " + refMember.getClass());
System.out.println(refMember.getName());
System.out.println("초기화 후 = " + refMember.getClass());
위 코드 실행 결과, 초기화 전의 refMember.getClass()
의 결과나 프록시 초기화 후의 refMember.getClass()
의 결과나 둘 다 같은 프록시 객체이다. (ex, Member$HibernateProxy...
이와 관련해서 겪은 문제
order -> member/delivery 조회는 다대일, 일대일 조회이고, order -> orderItem, orderItem -> item 조회는 일대다 조회인 경우이다. 그리고 모두 지연 로딩으로 설정되어 있다.
이때, order를 조회한 후 order 엔티티를 직접 노출하는 예제이다.@RestController @RequiredArgsConstructor @Slf4j public class OrderApiController { private final OrderRepository orderRepository; // 엔티티 직접 노출 (Hibername5Module로 프록시 강제 초기화 설정 필요) @GetMapping("/api/v1/orders") public List<Order> ordersV1() { List<Order> all = orderRepository.findAllByString(new OrderSearch()); // 프록시 객체 초기화 for (Order order : all) { order.getMember().getName(); // member 프록시 초기화 order.getDelivery().getAddress(); // delivery 프록시 초기화 List<OrderItem> orderItems = order.getOrderItems(); orderItems.stream().forEach(o -> o.getItem().getName()); // orderItem, item 프록시 초기화 } return all; } }
order를 조회한 결과를 담은 Order 리스트인 all을 그냥 반환하면, 지연 로딩으로 설정되어 있기 때문에 member, delivery, orderItem, item이 모두 프록시 객체이다. 따라서 다음과 같이 프록시 객체를 초기화해주고 all을 반환했다.
// 프록시 객체 초기화 for (Order order : all) { order.getMember().getName(); // member 프록시 초기화 order.getDelivery().getAddress(); // delivery 프록시 초기화 List<OrderItem> orderItems = order.getOrderItems(); orderItems.stream().forEach(o -> o.getItem().getName()); // orderItem, item 프록시 초기화 }
그런데 여전히 다음과 같은 오류가 발생했다.
com.fasterxml.jackson.databind.exc.InvalidDefinitionException: No serializer found for class org.hibernate.proxy.pojo.bytebuddy.ByteBuddyInterceptor and no properties discovered to create BeanSerializer
이는 jackson 라이브러리가 프록시 객체를 json 형태로 변환할 수 없어서 발생하는 오류이다.분명 order와 관련된 member, delivery, orderItem, item 프록시를 초기화해줬는데.. 왜 json 형태로 변환이 안되지? 라고 생각했다.
그러나 프록시를 초기화해줘도 프록시는 여전히 프록시로 존재한다는 것을 잊고 있었다..! 프록시를 초기화하면, 프록시를 통해 실제 엔티티에 접근할 수 있는 것일 뿐! 프록시는 여전히 프록시로 존재한다! 따라서 여전히 jackson 라이브러리는 프록시 객체를 json으로 변환하지 못하고 오류가 발생했던 것이다.
만약 초기화된 프록시를 정상적으로 json 형태로 응답하고 싶으면, Hibernate5Module을 스프링 빈으로 등록하면 된다. Hibernate5Module은 초기화되지 않은 프록시는 null로 응답하고, 초기화된 프록시는 정상적으로 json 형태로 응답한다.
프록시 객체는 실제 엔티티가 아니라, 실제 엔티티를 상속받은 객체이다. 따라서 프록시 객체는 타입 체크 시 주의해서 사용해야 한다(Member
!= Member$HibernateProxy
). 프록시 객체는 원본 엔티티를 상속받기 때문에, 타입 체크 시에 instanceOf
를 사용하면 된다.
Member m1 = em.find(Member.class, member1.getId());
Member m2 = em.find(Member.class, member2.getId());
System.out.println(m1.getClass() == m2.getClass()); //true
Member m1 = em.find(Member.class, member1.getId());
Member m2 = em.getReference(Member.class, member2.getId());
System.out.println(m1.getClass() == m2.getClass()); //false (Member != Member$HibernateProxy)
Member m1 = em.find(Member.class, member1.getId());
Member m2 = em.getReference(Member.class, member2.getId());
System.out.println(m1 instanceOf Member); //true
System.out.println(m2 instanceOf Member); //true
특정 변수에 실제 엔티티가 들어올지 프록시 객체가 들어올지 알 수 없기 때문에, JPA에서 타입을 비교할 때는 ==
보다 instanceOf
를 사용하는 것이 좋다.
만약 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 데이터베이스를 조회할 필요가 없으므로, em.getReference()를 호출해도 프록시가 아닌 실제 엔티티가 반환된다.
Member findMember = em.find(Member.class, member.getId());
System.out.println(findMember.getClass()); //Member (findMember는 실제 엔티티 객체이다.)
Member refMember = em.getReference(Member.class, member.getId());
System.out.println(refMember.getClass()); //Member (refMember도 실제 엔티티 객체이다.)
JPA는 == 비교의 결과를 true로 반환하기 위해 em.find()의 결과로 실제 엔티티 객체가 아닌 프록시 객체를 반환하기도 한다.
Member refMember = em.getReference(Member.class, member.getId());
System.out.println(refMember.getClass()); //Member$HibernateProxy (refMember는 프록시 객체이다.)
Member findMember = em.find(Member.class, member.getId());
System.out.println(findMember.getClass()); //Member$HibernateProxy (findMember도 프록시 객체이다.)
System.out.println(refMember == findMember); //true
위 코드에서 만약 em.getReference()의 결과로 프록시 객체가 반환되고 em.find()의 결과로 실제 엔티티 객체가 반환되면, refMember == findMember
의 결과는 false가 된다. jpa는 ==
비교 결과로 true를 반환하기 위해서, 이 경우 em.find()의 결과로 프록시 객체를 반환한다.
초기화는 영속성 컨텍스트의 도움을 받아야 가능하다. 따라서 준영속 상태의 프록시를 초기화하면 문제가 발생한다. 하이버네이트는 LazyInitializationException 예외를 발생시킨다.
Member refMember = em.getReference(Member.class, member.getId());
em.detach(refMember); //refMember를 준영속 상태로 (em.clear(), em.close()를 해도 같다)
refMember.getName(); //초기화 시도, 예외 발생
JPA가 제공하는 PersistenceUnitUtils.isLoaded()
메소드를 통해 프록시 인스턴스의 초기화 여부를 확인할 수 있다. 초기화되지 않은 프록시 인스턴스이면 false를, 초기화되었거나 프록시 인스턴스가 아니면 true를 반환한다.
//방법 1
boolean isLoad = em.getEntityManagetFactory().getPersistenceUnitUtils.isLoaded(entity);
//방법 2
boolean isLoad = emf.getPersistenceUnitUtils.isLoaded(entity);
하이버네이트의 initialize()
메소드를 통해 프록시를 강제로 초기화할 수 있다.
참고로 JPA 표준에는 프록시 강제 초기화 메소드가 없기 때문에, 강제로 초기화하려면 member.getName()
처럼 프록시의 메소드를 호출하면 된다. JPA 표준은 단지 초기화 여부만 확인할 수 있다.
회원 엔티티를 조회할 때 연관된 팀 엔티티도 함께 데이터베이스에서 조회하는 것이 좋을까? 아니면 회원 엔티티만 조회해 두고 팀 엔티티는 실제 사용하는 시점에 데이터베이스에서 조회하는 것이 좋을까?
JPA는 개발자가 연관된 엔티티의 조회 시점을 선택할 수 있도록 즉시 로딩과 지연 로딩, 두 가지 방법을 제공한다.
즉시 로딩은 엔티티를 조회할 때 연관된 엔티티도 함께 조회한다.
ex, em.find(Member.class, "member1")
을 호출할 때 회원 엔티티와 연관된 팀 엔티티도 함께 조회한다.
설정 방법: @MantToOne(fetch = FetchType.EAGER)
@Entity
public class Member {
@ManyToOne(fetch = FetchType.EAGER)
@JoinColumn(name = "team_id")
private Team team;
}
Member member = em.find(Member.class, "member1");
Team team = member.getTeam(); //team은 실제 엔티티 객체이다.
지연 로딩은 연관된 엔티티를 실제 사용할 때 조회한다.
ex, member.getTeam().getName()
처럼 조회한 팀 엔티티를 실제 사용하는 시점에 JPA가 SQL을 호출해서 팀 엔티티를 조회한다.
설정 방법: @MantToOne(fetch = FetchType.LAZY)
@Entity
public class Member {
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "team_id")
private Team team;
}
Member member = em.find(Member.class, "member1");
Team team = member.getTeam(); //team은 프록시 객체이다.
team.getTeam(); //이 시점에 실제 데이터베이스를 조회하고 프록시 객체가 초기화된다.
fetch 속성의 기본 설정값은 다음과 같다.
@ManyToOne
, @OneToOne
: 즉시 로딩(FetchType.EAGER)
@OneToOne
, @ManyToMany
: 지연 로딩(FetchType.LAZY)
즉시 로딩으로 설정하면 인식하지 못하는 부분에서 join sql이 데이터베이스로 나가는 문제가 발생한다. 만약 하나의 엔티티에 연관된 엔티티가 10개라면, 해당 엔티티를 조회할 때 10개의 테이블과 조인하는 sql이 나가게 된다. 따라서 모든 연관관계를 지연 로딩으로 설정해야 한다.