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

프록시와 즉시로딩, 지연로딩:

객체는 객체 그래프로 연관된 객체들을 탐색한다. 그런데 객체가 db에 저장되어 있으므로 연관된 객체를 마음껏 탐색하기 어렵다. JPA 구현체들은 이 문제를 해결하려고 프록시라는 기술을 사용한다.

프록시를 사용하면 연관된 객체를 처음부터 db에서 조회하는 것이 아니라, 실제 사용하는 시점에 db에서 조회할 수 있다.

하지만 자주 함께 사용하는 객체들은 조인을 사용해서 함께 조회하는 것이 효과적이다.

JPA는 즉시 로딩과 지연 로딩이라는 방법으로 둘을 모두 지원한다.

 

영속성 전이와 고아 객체: 

JPA는 연관된 객체를 함께 저장,삭제 할 수 있는 영속성 전이와 고아객체 제거라는 편리한 기능을 제공한다.

 

8.1 프록시

엔티티를 조회할 때 연관된 엔티티들이 항상 사용되는 것은 아니다. 예를 들어 회원 엔티티를 조회할 때 연관된 팀 엔티티는 비즈니스 로직에 따라 사용 유무가 달라진다.

@Entity
public class Member {
    private String username;
    
    @ManyToOne
    private Team team;
    ...
}
@Entity
public class Team{
    private String name;
    ...
}
 
//회원과 팀 정보를 출력하는 비즈니스 로직
public void printUserAndTeam(String memberId){
    Member member=em.find(Member.class,memberId);
    Team team=member.getTeam();
    print(member.getUsername());
    print(team.getName());
}
//회원정보만 출력하는 비즈니스 로직
public void printUserAndTeam(String memberId){ 
    Member member=em.find(Member.class,memberId);
    print(member.getUsername());
}
 

 

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

JPA는 이런 문제를 해결하려고 엔티티가 실제 사용될 때까지 db조회를 지연하는 방법을 제공하는데 이것을 지연 로딩이라 한다. 

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

이 방법을 사용하면 printUser()메소드는 회원 데이터만 db에서 조회해도 된다.

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

 

8.1.1 프록시 기초

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

이 메소드는 영속성 컨텍스트에 엔티티가 없으면 db를 조회한다.

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

이렇게 엔티티를 직접 조회하면 조회한 엔티티를 실제 사용 유무를 떠나서 db에 조회하게 된다.

엔티티를 실제 사용하는 시점까지 db조회를 미루고 싶으면 EntityManager.getReference() 메소드를 사용하면 된다.

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

 이 메소드를 호출할 때 JPA는 db를 조회하지 않고 실제 엔티티 객체도 생성하지 않는다. 대신 db접근을 위임한 프록시 객체를 반환한다.

 

프록시의 특징

프록시 클래스는 실제 클래스를 상속 받아서 만들어지므로 실제 클래스와 겉 모양이 같다.

따라서 사용자는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 됨.

 

프록시 객체는 실체 객체에 대한 참조(target)를 보관한다. 그리고 프록시 객체의 메소드를 호출하면 프록시 객체는 실제 객체의 메소드를 호출한다. 

 

프록시 객체의 초기화

프록시 객체는 member.getName() 처럼 실제 사용될 때 db를 조회해서 실제 엔티티 객체를 생성하는데 이것을

프록시 객체의 초기화라 한다. 

Member member = em.getReference(Member.class, "id1");
 
member.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. 영속성 컨텍스트는 db를 조회해서 실제 엔티티 객체를 생성한다.
4. 프록시 객체는 생성된 실제 엔티티 객체의 참조를 Member target 멤버 변수에 보관.
5. 프록시 객체는 실제 엔티티 객체의 getName()을 호출해서 결과 반환.

프록시의 특징

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

준영속 상태와 초기화

//MemberProxy 반환

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

transaction.commit();

em.close(); //영속성 컨텍스트 종료

 

member.getName(); // 준영속 상태 초기화 시도.

                          //  org.hibernate.LazyInitializationException 예외 발생.

 

위 코드를 보면 em.close() 메소드로 영속성 컨텍스트를 종료해서 member는 준영속 상태이다.

member.getName()을 호출하면 프록시를 초기화 해야 하는데 영속성 컨텍스트가 없으므로 실제 엔티티를 조회할 수 없다. 따라서 예외가 발생.

 

8.1.2 프록시와 식별자

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

 

 Team team= em.getReference(Team.class, "team1"); //식별자 보관

 team.getId(); //초기화X

 

프록시 객체는 식별자 값을 가지고 있으므로 식별자 값을 조회하는 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);
 

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

 연관관계를 설정할 떄는 식별자 값만 이용하므로 프록시를 사용하면 db접근 횟수를 줄일 수 있다.

참고로 연관관계를 설정할 때는 엔티티 접근 방식을 필드로 설정해도 프록시를 초기화하지 않음.

 

8.2 즉시 로딩과 지연 로딩

프록시 객체는 주로 연관된 엔티티를 지연 로딩할 때 사용한다. 

member1이 team1에 소속해 있다고 가정해보자. 

 

Member member = em.find(Member.class, "member1");
Team team= member.getTeam(); // 객체 그래프탐색
System.out.println(team.getName()); // 팀 엔티티 

회원 엔티티를 조회할 때 연관된 팀 엔티티도 함께 db에서 조회하는 것이 좋을까? 아니면 회원 엔티티만 조회해 두고 팀 엔티티는 실제 사용하는 시점에 db에서 조회하는 것이 좋을까?

 JPA는 개발자가 연관된 엔티티 조회 시점을 선택할 수 있도록 2가지 방법을 제공한다.

 

즉시 로딩: 엔티티를 조회할 때 연관된 엔티티도 함께 조회한다. 

지연 로딩:연관된 엔티티를 실제 사용할 때 조회한다.

 

8.2.1 즉시 로딩

@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(); // 객체 그래프탐색
 

회원과 팀을 즉시로딩으로 설정했다. 따라서 회원을 조회하는 순간(em.find) 팀도 함께 조회한 것 같다.

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

 

SELECT
    M.MEMBER_ID AS MEMBER_ID,
    M.TEAM_ID AS TEAM_ID,
    M.USERNAME AS USERNAME,
    T.TEAM_ID AS TEAM_ID,
    T.NAME AS NAME
FROM
    MEMBER M LEFT OUTER JOIN TEAM T
        ON M.TEAM_ID=T.TEAM_ID
WHERE
    M.MEMBER_ID='member1'

 이 SQL을 분석해보면 회원과 팀을 조인해서 쿼리 한 번으로 조회한 것을 알수 있다.

 이후 member.getTeam()을 호출하면 이미 로딩된 팀1 엔티티를 반환한다.

 

LEFT OUTER JOIN 개념 참조 :server-engineer.tistory.com/306

 

현재 회원 테이블에 TEAM_ID 외래 키는 NULL 값을 허용하고 있다. 따라서 팀에 소속되지 않은 회원이 있을 가능성이 있다. 회원과 팀을 내부 조인하면 팀에소속하지 않은 회원데이터를 조회할 수 없다.

JPA는 이런 상황을 고려해서 외부 조인을 사용한다. 하지만 외부 조인보다 내부 조인이 성능과 최적화에 유리하다.

그럼 내부 조인을 사용하는 방법은? 외래 키에 NOT NULL 제약 조건을 설정하면 값이 있는 것을 보장한다.

따라서 이때는 내부 조인만 사용해도 된다.

@ManyToOne~~~

@JoinColumn(name="TEAM_ID",nullable=false) 

 

nullaber 설정에 따른 조인 전략

• @JoinColumn(nullable=true):NULL 허용, 외부조인
• @JoinColumn(nullable=false):NULL 비허용,내부 조인

또는 다음처럼 @ManyToOne(fetch=FetchType.EAGER,optional=false)라고 설정해도 내부 조인을 사용.

 

8.2.2 지연 로딩

@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.getName(); //팀 객체 실제 

지연 로딩,회원 조회 시 팀 지연 로딩

 em.find를 호출하면 회원만 조회하고 팀은 조회하지 않는다. 대신 조회한 회원의 team 멤버변수에 프록시 객체를 넣어둔다.

 Team team=member.getTeam(); //프록시 객체

반환된 팀 객체는 프록시 객체다. 이 프록시 객체는 실제 사용될 떄까지 데이터 로딩을 미룬다.

 team.getName(); //팀 객체 실제 사용

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

em.find 호출 시 실행되는 SQL은 다음과 같다.

 

SELECT * FROM MEMBER
WHERE MEMBER_ID='MEMBER1'
 
team.getName() 호출로 프록시 객체가 초기화 되면 실행되는 SQL
 
SELECT * FROM TEAM
WHERE TEAM_ID='team1'

 

정리

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

8.3.2 JPA 기본 페치 전략

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

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

JPA의 기본 페치 전략은 연관된 엔티티가 하나면 즉시로딩을, 컬렉션이면 지연 로딩을 사용함.

컬렉션을 로딩하는 것은 비용이 많이 들고 잘못하면 너무 많은 데이터를 로딩할 수 있기 때문.

예를 들어 특정 회원이 연관된 컬렉션에 데이터를 수만 건 등록했는데, 설정한 페치 전략이 즉시 로딩이면 해당 회원을 로딩하는 순간 수만 건의 데이터도 함께 로딩된다. 반면에 연관된 엔티티가 하나면 즉시 로딩해도 큰 문제가 발생X.

 추천하는 방법은 모든 연관관계에 지연 로딩을 사용하는 것.

 

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

• 컬렉션을 하나 이상 즉시 로딩하는 것은 권장X: 컬렉션과 조인한다는 것은 db테이블로 보면 일대다 조인이다. 일대다 조인은 결과 데이터가 다 쪽에 있는 수만큼 증가하게 된다. 문제는 서로 다른 컬렉션을 2개 이상 조인할 때 발생하는데 예를 들어 A 테이블을 N,M 두 테이블과 일대다 조인하면 SQL 실행 결과가 N곱하기 M이 되면서 너무 많은 데이터를 반환. 결과적으로 app 성능 저하됨.
• 컬렉션 즉시 로딩은 항상 외부 조인을 사용한다: 예를 들어 대다일 관계인 회원 테이블과 팀 테이블을 조인할 때 회원 테이블의 외래 키에 not null 제약 조건을 걸어두면 모든 회원은 팀에 소속되므로 항상 내부조인 사용 가능. 반대로 팀 테이블에서 회원 테이블로 일대다 관계를 조인할 때 회원이 한명도 없는 팀을 내부 조인하면 팀까지 조회되지 않는 문제 발생. db 제약조건으로 이런 상황을 막을 수 없다. 따라서 JPA는 일대다 관계를 즉시 로딩할 때 항상 외부조인을 사용.

@ManyToOne, @OneToOne

-(optional =false): 내부 조인

-(optional=true): 외부 조인

 

@OneToMany,@ManyToMany

-(optional =false): 외부 조인

-(optional=true): 외부 조인