[JPA] 자바 ORM 표준 JPA 프로그래밍 - 기본편 #8. 프록시와 연관관계 관리

bien·2024년 1월 28일
JPA
1

jpa-basic

목록 보기
6/6

프록시

프록시의 필요성

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

Member 엔티티가 Team을 연관관계를 가진 필드변수로 가지고 있다. 만약 Member에서 Team에 대한 정보가 필요없고 그 외 Member와 관련된 정보만 필요한 상황이라면, 이런 경우에도 Member와 Team 정보를 동시에 조회해야 할까?

회원과 팀 함께 출력

public void printUserAndTeam(String memberId) {
	Member member = em.find(Member.class, memberId);
    Team team = member.getTeam();
    
    // Member와 Team 정보를 모두 사용하고 있다.
    System.out.println("회원 이름: " + member.getUsername());
    System.out.println("소속팀: " + team.getName());
}

회원만 출력

public void printUser(String memberId) {
	Member member = em.find(Member.class, memberId);
    Team team = member.getTeam();
    
    // Member 정보만 사용하고 있다.
    System.out.println("회원 이름: " + member.getUsername());
}

비지니스 로직 상 항상 두 가지 엔티티를 모두 가져오는 상황과, 주로 하나의 엔티티를 가져오고 다른 연관관계 엔티티는 드물게 필요한 상황이 있을 수 있다. 이런 경우를 위해 JPA가 프록시라는 기술을 제공하고 있다.

프록시 기초

  • em.find() vs em.getReference()
  • em.find()
    • 데이터베이스를 통해서 실제 엔티티 객체 조회
    • find() 메서드를 호출해 엔티티를 직접 조회하면 엔티티 실제 사용 여부를 떠나 데이터베이스를 조회하게 된다.
  • em.getReference()
    • 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회
    • 엔티티를 실제 사용하는 시점까지 데이터베이스 조회를 미루고 싶으면 getReference() 메소드를 사용하면 된다.
      • 프록시 객체는 위의 사진과 같은 형태다. 껍데기는 엔티티와 동일하지만, 내부의 내용이 비어있다.
      • 내부에는 Target이 있는데, 이것이 진짜 레퍼런스를 가리킨다. (초기에는 비어있다.)
      • 프록시라는 껍데기 객체에 ID값만 가지고 있는 가짜가 반환된다.

참고) JPA 표준 명세는 지연 로딩의 구현 방법을 JPA 구현체에 위임했다. 따라서 이후에 설명되는 내용은 하이버네이트 구현체에 대한 내용이다. 하이버네이트는 지연 로딩을 지원하기 위해 프록시를 사용하는 방법과 바이트코드를 수정하는 두 가지 방법을 제공하는데, 바이트 코드를 수정하는 방법은 설정이 복잡하므로 여기서는 별도의 설정이 필요 없는 프록시에 대해서만 알아본다. 바이트코드를 수정하는 방법은 하이버네이트 공식 사이트를 참고하자.

Member findMEmber = em.getReference(Member.class, member.getId());
Systemm.out.println("findMember = " + findMember.getClass());

System.out.println("findMember.id = " + findMember.getId()); 
System.out.println("findMember.username = " + findMember.getUsernane());
  • 위의 코드를 실행하면 한 번의 SELECT문만 실행된다.
    • 이는 Reference를 찾는 시점에 이미 아이디 값을 주입했기 때문이다. 해당 값이 이미 주입되어 있으므로 JPA측에서 해당 엔티티를 추가적으로 터치하지 않는다(DB에 쿼리를 날리지 않는다.)
    • 그러나 getUsernmae()을 호출할 때는 해당 정보가 비어있고 DB에만 있기 때문에 JPA가 DB에 쿼리를 날려준다.

프록시 특징

  • 실제 클래스를 상속 받아서 만들어짐. 따라서 실제 클래스와 겉 모양이 같다.
    • 개발자가 상속한것이 아니라 Hibernate가 내부적으로 라이버리를 써서 생성한다.
  • 사용하는 입장에서는 진짜 객체인지 프록시 객체인지 구분하지 않고 사용하면 됨. (이론상)
    • 다만 몇가지 주의사항이 있어 알아두면 좋다. (추후 기술)

  • 프록시 객체는 실제 객체의 참조(target)를 보관
  • 프록시 객체를 호출하면 프록시 객체는 실제 객체의 메소드 호출

프록시 객체 초기화

프록시 초기화 예제

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

프록시 주의사항

1. 프록시 객체는 처음 사용할 때 한번만 초기화한다.

2. 프록시 객체를 초기화할 때, 프록시 객체가 실제 엔티티로 바뀌는 것은 아니다.

즉, 교체되는 것이 아니라 내부의 값만 채워지는 것이다. 따라서 초기화되면 프록시 객체를 통해서 실제 엔티티에 접근 가능하다.

Member member = em.getReference(Member.class, "id1");
Systemm.out.println("before findMember = " + findMember.getClass()); 
// MemberProxy객체1
System.out.println("findMember.username = " + findMember.getUsernane());
Systemm.out.println("after findMember = " + findMember.getClass()); 
//MemberProxy객체 1. 위와 동일한 객체를 반환한다.

3. 프록시 객체는 원본 엔티티를 상속받는다. 따라서 타입 체크에 주의해야 한다.

참고) 영속 엔티티의 동일성 보장

Member a = em.find(Member.class, "member1");
Member b = em.find(Member.class, "member1");
System.out.println(a == b); // 동일성 비교

JPA를 이용하면 member1이라는 동일한 식별자(id)를 가진 객체를 반복해서 호출할 때 1차 캐시에 있는 같은 엔티티 인스턴스를 반환한다. 따라서 영속성 컨텍스트는 엔티티의 동일성을 보장한다.

  • ==: 비교에 실패한다.
  • 대신 instance of 사용해야 한다.

== 비교: em.find 2개

Member m1 = em.find(Member.class, member1.getId());
Member m2 = em.find(Member.class, member2.getId());

System.out.println("m1 == m2" + (m1.getClass() == m2.getClass())); // true
  • 당연히 JPA에서 두 객체는 동일한 객체로 취급된다.

== 비교: em.find & em.getReference

Member m1 = em.find(Member.class, member1.getId());
Member m2 = em.getReference(Member.class, member2.getId());

System.out.println("m1 == m2" + (m1.getClass() == m2.getClass())); // false
  • == 비교는 정확히 같은 객체일 때에만 true를 반환한다.
    • m1과 m2가 상속관계이므로, false가 반환되었다.

instanceof 비교:

Member m1 = em.find(Member.class, member1.getId());
Member m2 = em.getReference(Member.class, member2.getId());

System.out.println("m1 instanceof Member" + (m1 instanceof Member)); // true
System.out.println("m2 instanceof Member" + (m1 instanceof Member)); // true
  • instanceof: 자바의 객체 타입 확인에 사용되는 연산자. 주어진 객체가 특정 클래스나 해당 클래스를 상속받은 클래스의 인스턴스인지를 확인한다.
    • JPA에서는 프록시가 기존 엔티티를 상속받는 방식으로 구현되기 때문에, 타입을 비교해야 하는 일이 있는 경우 instanceof를 사용해주는 것이 좋다.

4. 영속성 컨텍스트에 찾는 엔티티가 이미 있으면 em.getReference()를 호출해도 실제 엔티티를 반환한다.

1) 엔티티 호출 후 프록시 호출

Member m1 = em.find(Member.class, member1.getId());
System.out.println("m1 = " + m1.getClass()); 
	// 진짜 객체 hellojpa.Member 반환.

Member reference = em.getReference(Member.class, member1.getID());
System.out.println("reference = " + reference.getClass()); 
	// 여기서 무엇이 출력될까?
    // 여기서도 실제 엔티티 객체 hellojpa.Member를 반환한다.
  • 엔티티를 먼저 호출하고(em.find) 이후 레퍼런스(em.getReference)를 호출했다. 엔티티의 클래스를 출력할 때는 hellojpa.Member라는 실제 엔티티 클래스 값이 호출된다. reference의 클래스를 찍어보면 어떤 값이 출력될까?
    • 먼저 JPA에서는 같은 영속성 컨텍스트 내에서(같은 트랜잭션 내에서) 동일한 인스턴스의 == 비교에 대해서 동일함을 보장해야 한다는 점을 고려하자.
  • reference로 획득한 proxy 객체 역시 class명을 찍어보면 hellojpa.Member라는 실제 엔티티명이 출력된다.
    • 이미 가져온 엔티티를 다시 프록시로 변경할 필요가 없기 때문에, 영속성 컨텍스트에 이미 엔티티가 있는 경우 프록시를 호출하더라도 엔티티를 호출해준다.

2) 프록시 호출 후 엔티티 호출

Member refMember = em.getReference(Member.class, member1.getId());
System.out.println("refMember = " + refMember.getClass()); 
	// 프록시 객체 반환

Member findMember = em.find(Member.class, member1.getID());
System.out.println("findMember = " + findMember.getClass()); 
	// 실제 엔티티를 호출했지만, 프록시 객체를 반환한다.
  • 프록시 객체를 호출하고(em.getReference) 이후 실제 엔티티를 호출(em.find)했다. 프록시 객체 후 엔티티 객체를 호출 할때에는 어떤 클래스 값이 출력 될까?
    • 앞서 언급한 것처럼, JPA는 같은 영속성 컨택스트 내에서(트랜잭션 내에서) 동일한 인스턴스의 == 비교에 대해 동일성을 보장해야 한다는 것을 기억하자.
  • 이후 엔티티 클래스 값으로 프록시 객체가 출력된다.
    • == 비교를 맞추기 위해 JPA에서 em.find를 통해 실제 엔티티를 호출하더라도 프록시 객체를 반환해준다.
    • 실제로 실무에서는 이렇게 복잡할 일이 거의 없으니, 단순히 JPA에서는 어떻게든 ==연산이 가능하도록 스펙이 갖추어져 있다는 사실만 기억하면 된다.

📌 내 요약

JPA는 같은 트랜잭션(영속성 컨텍스트) 내에서 같은 식별자는 같은 인스턴스로 다룰 수 있도록 도와준다. 그러나 엔티티를 다루는 과정에서 '프록시'를 사용하고 있어 객체의 동일성 비교에 어려움이 있다. (구체적인 구현 로직은 굳이 외우지말고) 단순히 JPA측에서 '프록시' 사용에도 불구하고 == 비교가 가능하도록 지원하고 있음을 기억하자.

5. 영속성 컨텍스트의 도움을 받을 수 없는 준영속 상태일 때, 프록시를 초기화하면 문제가 발생한다.

Member refMember = em.getReference(Member.class, member1.getId());
System.out.println("refMember = " + refMember.getClass()); // Proxy

em.detach(refMember); // 호출 객체 준영속 상태
em.close(); // 영속성 컨텍스트 초기화

refMember.getUsername();

org.hibernate.LazyInitializationException: could not initialize proxy [hellojpa.Member#1] - no Session

  • 하이버네이트는 org.hibernate.LazyInitializationException 예외를 터뜨린다.
    • 위의 상태처럼 프록시 생성 이후 해당 프록시의 값을 초기화하는데 사용되어야 할 엔티티가 더이상 참고할 수 없는 상황일 때(준영속 상태이거나 영속성 컨텍스트가 종료된 상황), 예외를 터뜨린다.

⭐️ 프록시와 식별자

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

Team team = em.getReference(Team.class, "team1"); // 식별자 보관
team.getId(); // 초기화되지 않음

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

프록시 확인

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

즉시 로딩과 지연 로딩

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

앞서 물었던 질문을 다시 확인해보자. Member 엔티티를 호출할 때 Team이라는 연관관계 정보가 필요하지 않고 다른 필드 정보만 필요한 상황이라면, 이런 경우에도 Member와 Team 정보를 동시에 조회해야 할까?

위의 질문을 해결하고자, JPA는 필요에 따라 연관관계 정보를 함께 조회할지 그 여부를 선택할 수 있는 설정을 제공하고 있다. 프록시를 이해했다면 이 기능을 쉽게 이해할 수 있다.

바로 프록시라는 기능을 이용해 JPA에서는 가짜 객체들을 넣어둔다. 그리고 실제로 내부의 필드를 사용하는 시점에서 DB에 초기화 쿼리가 날아가 해당 데이터를 채워둔다. 즉, 팀을 사용하는 것이 아니라 팀의 특정 값을 사용할 때 팀의 정보를 호출한다. (getTeam 호출 시점이 아니라 team.getName() 호출 시점에 team의 정보를 초기화한다.) 이와 같은 기능을 지연 로딩(Lazy loading)이라고 한다.

즉시로딩 & 지연로딩 요약

  • 즉시 로딩 (Eager Loading): 엔티티를 조회할 때 연관된 엔티티도 함께 조회한다.
    • em.find(Member.class, "memer1")를 호출할 때 회원 엔티티와 관련된 팀 엔티티도 함께 조회한다.
    • 설정방법: @ManyToOne(fetch = FetchType.EAGER)
  • 지연 로딩 (Lazy Loading): 연관된 엔티티를 실제 사용할 때 조회한다.
    • member.getTeam().getName()처럼 조회한 팀 엔티티를 실제 사용하는 시점에 JPA가 SQL을 호출해 팀 엔티티를 조회한다.
    • 설정방법: @ManyToOne(fetch = FetchType.LAZY)

즉시 로딩

즉시 로딩 설정

@Entity
public class Member {
	// ...
    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "TEAM_ID")
    private Team team;
    // ...
}
  • @ManyToOne의 fetch 속성을 FetchType.EAGER로 지정한다.

즉시 로딩 실행 코드

Member member = em.find(Member.class, "member1");
Team tema = member.getTeam(); // 객체 그래프 탐색

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

즉시 로딩 실행 SQL

SELECT
	M.meberId as member_id,
    M.teamId as team_id,
    M.username as username,
    T.teamId 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';

NULL 제약조건과 JPA 조인 전략

JPA가 내부 조인(INNER JOIN)이 아닌 외부조인 (LEFT OUTER JOIN)을 사용한 것을 유심히 봐야한다. 현재 회원 테이블에 TEAM_ID 외래 키는 NULL값을 허용하고 있다. 따라서 TEAM에 소속되지 않은 회원이 있을 가능성이 있다. 팀에 소속하지 않은 회원과 팀을 내부 조인하면 팀은 물론이고 회원 데이터도 조회할 수 없다.

JPA는 이런 상황을 고려해 외부 조인을 사용한다. 하지만 외부 조인보다 내부 조인이 성능과 최적화에 더 유리하다. 그럼 내부 조인을 사용하려면 어떻게 해야할까? 외래 키에 NOT NULL 제약 조건을 설정하면 값이 있는것을 보장하고, 따라서 내부 조인이 사용 가능해진다.

JPA에게 null 값 허용여부를 알려주려면 @JoinColumn(nullable = false) 설정을 사용하면 된다.

@Entity
public class Member {

	//...
    @ManyToOne(fetch = FetchType. EAGER)
    @JoinColmn(name = "TEAM_ID", nullable = false)
    private Team team;
}

nullable 설정에 따른 조인 전략

  • @Join(nullable = true): Null값 허용(기본값), 외부 조인 허용
  • @Join(nullable = false) : Null값 비허용, 내부 조인 사용

지연 로딩

지연 로딩 설정

@Entity
public class Member {
	// ...
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "TEAM_ID")
    private Team team;
    // ...
}
  • @ManyToOne의 fetch 속성을 FetchType.LAZY로 지정한다.

지연 로딩 실행 코드

Member member = em.find(Member.class, "member1");
Team tema = member.getTeam(); // 객체 그래프 탐색
team.getName(); // 팀객체 실제 사용
  • member.getTeam()으로 호출되는 팀 객체는 프록시 객체다. 이 프록시 객체는 실제 사용도리 때까지 데이터 로딩을 미룬다. 그래서 지연로딩이라고 한다.

지연 로딩 실행 SQL

  • em.find(Member.class, "member1")
SELECT + FROM member
WHERE member_id

프록시와 즉시로딩 주의

  • 가급젹 지연 로딩만 사용(특히 실무에서)
    • '조인으로 한번에 정보를 가져오면 좋지 않을까?'라는 생각으로 즉시로딩이 긍정적으로 생각될 수 있다. 그러나 실무에서는 모든 연관관계를 지연로딩으로 설정하는 것을 권장한다.
  • 즉시 로딩을 적용하면 예상하지 못한 SQL이 발생한다.
    • 내부에서 최적화가 이루어지는 jpa와 달리, sql로 바로 번역되는 JPQL의 경우 즉시 로딩을 미리 알 수 없어 DB조회 이후 연관관계 정보를 위해 다시 SQL을 날리는 형식으로 실행된다.
Member member1 = new Member();
member1.setUsername("member1");
member1.setTeam(team);
em.persist(member1);

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

List<Member> members = em.createQuery("select m from Member m", Member.class)
	.getResultList();

//SQL: select * from Member;
//SQL: select * from Team where TEAM_ID = xxx
  • 즉시로딩은 JPQL에서 N+1 문제를 일으킨다.
    • 최초로 조회한 엔티티 1개와, 그 엔티티와 관련된 매핑 정보 N개가 모두 조회된다는 이유로 N+1 문제라고 부른다.
      • 아래 예시에서는 먼저 Member를 조회하고, 각각 member1, member2와 연결된 TeamA, TeamB를 조회하기 위해 2번의 추가 쿼리가 날아가게 된다.
    • Lazy 설정을 적용하는 경우 N개의 매핑 정보들이 빈 프록시로 매핑되어 있어 추가 조회가 날아가지 않는다는 장점이 있다.
    • N+1 문제는 패치 조인, 엔티티 그래프 또는 배치 사이즈를 통해 해결할 수 있다.
Team teamA = new Team();
teamA.setName("teamA");
em.persist(teamA);

Team teamB = new Team();
teamA.setName("teamB");
em.persist(teamB);

Member member1 = new Member();
member1.setUsername("member1");
member1.setTeam(teamA);
em.persist(member1);

Member member2 = new Member();
member1.setUsername("member2");
member1.setTeam(teamB);
em.persist(member1);


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

List<Member> members = em.createQuery("select m from Member m", Member.class)
	.getResultList();
  • XtoOne은 기본이 즉시 로딩 -> 따로 Lazy로 설정해야 한다.
    • @ManyToOne, @OneToOne
  • XtoMany는 기본이 지연 로딩
    • @OneTOMany, @ManyToMany

지연 로딩 활용

  • 이론적 예시가 다음과 같다는 것이지, 실무에서는 지연 로딩만 사용해야 한다.
  • Member와 Team은 자주 함께 사용 => 즉시 로딩
  • Member와 Order는 가끔 사용 => 지연 로딩
  • Order와 Product는 자주 함께 사용 => 즉시 로딩

  • Member와 즉시 로딩으로 연결된 Team정보는 바로 불러오고, Order측 정보는 프록시로 다뤄진다.

프록시와 컬렉션 래퍼

Member member = em.find(Member.class, "member1");
List<Order> orders = member.getOrders();
System.out.println("orders = " + orders.getClass().getName());
// 결과: orders = org.hibernate.collection.internal.PersistentBag
  • 하이버네이트는 엔티티를 영속 상태로 만들 때 엔티티에 컬렉션이 있으면 컬레션을 추적하고 관리할 목적으로 원본 컬렉션을 하이버네이트가 제공하는 내장 컬렉션으로 변환하는데 이것을 컬렉션 래퍼라고 부른다.
  • 엔티티를 지연 로딩하면 프록시 객체를 사용해서 지연 로딩을 수행하지만 주문 내역 같은 컬렉션은 컬랙션 래퍼가 지연 로딩을 처리해준다. 컬렉션 래퍼도 컬렉션에 대한 프록시 역할을 수행한다.
  • member.getOrdres()를 호출해도 컬렉션은 초기화되지 않는다. meber.getOrders().get(0)처럼 실제 데이터를 조회할 때 데이터베이스를 조회해서 초기화한다.

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

  • 컬렉션을 하나 이상 즉시 로딩하는 것은 권장하지 않는다.

    • 컬렉션과 조인한다는 것은 데이터베이스 테이블로 보면 일대다 조인이다. 일대다 조인은 결과 데이터가 다 쪽에 있는 수만큼 증가하게 된다.
    • 문제는 서로 다른 컬렉션을 2개 이상 조인할 때 발생한다. 예를들어 A테이블을 N, M 두개의 테이블과 일대다 조인하면 SQL 실행 결과가 N 곱하기 M이 되면서 너무 많은 데이터를 반환해 애플리케이션 성능이 저하될 수 있다.
    • 따라서 2개이상의 컬렉션을 즉시 로딩하는 것은 권장하지 않는다.

  • 컬렉션 즉시 로딩은 외부 조인(OUTER JOIN)을 사용한다.

    • 다대일 관계인 회원과 팀 테이블을 조인할 때 회원 테이블의 외래키에 NOT NULL 제약조건을 걸어두면 모든 회원은 팀에 소속되므로 항상 내부 조인을 사용해도 된다.
    • 반대로 팀 테이블에서 회원 테이블로 일대다 관계를 조인할 때 회원이 한명도 없는 팀을 내부 조인하면 팀까지 조회되지 않는 문제가 발생한다. 데이터베이스 제약조건으로 이런 상황을 막을 방법은 없다.
    • 따라서 JPA는 일대다 관계를 즉시 로딩할 때 항상 외부 조인을 사용한다.

  • @ManyToOne, @OneToOne

    • (optional = false): 내부 조인
    • (optional = true): 외부 조인

  • @OneToMany, @ManyToMany

    • (optional = false): 외부 조인
    • (optional = true): 외부 조인

영속성 전이: CASCADE

  • 특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속상태로 만들 때 사용한다.
    • 즉, 부모를 저장할 때(persist호출) 자식도 같이 저장하고 싶은 경우 사용하는 옵션이다.
  • 엔티티 영속화 시 연관된 엔티티도 함께 영속화하는 편리함 제공 용도.
    • 연관관계나 즉시 혹은 지연 로딩과 아무런 관계가 없다.
  • 예: 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장

저장

Parent

@Entity
public class Parent {

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL) //**
    private List<Child> childList = new ArrayList<>();

    public void addChild(Child child) {
        childList.add(child);
        child.setParent(this);
    }
}

Child

@Entity
public class Child {

    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @ManyToOne
    @JoinColumn(name = "parent_id")
    private Parent parent;
}

엔티티 사용 코드

Child child1 = new Child();
Child child2 = new Child();

Parent parent = new Parent();
parent.addChild(child1);
parent.addChild(child2);

em.persist(parent);
// em.persist(child1);
// em.persist(child2);
  • parent에 포함된 child를 저장하기 위해 3번의 저장 코드(em.persist)가 작성되어야 한다.
  • 그러나 단순히 Parent에 영속성 전이 코드(cascade=CascadeType.PERSIST)를 추가하는 것 만으로 부모만 영속 상태로 만들어도 연관된 자식까지 한번에 영속 상태로 만들 수 있다.

종류

  • ALL: 모두 적용 (주로 ALL을 사용한다.)
  • PERSISTL: 영속 (저장시에만 영속성 전이를 적용하고 싶은 경우)
  • REMOVE: 삭제
  • MERGE: 병합
  • REFRESH: REFRESH
  • DETACH: DETACH

실무에서의 사용

실제에서도 연속성 전이(Cascade)설정을 빈번하게 사용된다. 그러나 이 영속성 전이는 부모가 오직 하나의 자식을 관리할때 사용하는 것을 추천한다.

예를 들어 첨부파일이 저장 가능한 게시판을 구현할 때, 첨부파일 테이블에 첨부파일 경로를 저장할 때 사용 가능하다. (첨부파일의 경로는 한 게시판에서만 관리가 되므로) 그러나 만약 파일을 여러 엔티티에서 관리하는 경우에는 사용하면 안된다. 즉, parent 엔티티만 child를 관리하면 상관없는데 다른 엔티티가 또 해당 child에 영향을 미치는 경우 사용하면 안된다. (이런 경우를 소유자가 하나일 때라고 한다.)

크게 두가지를 고려하면 된다.

  1. 단일 엔티티와 완전히 종속적일 때 영속성 전이 사용이 추천된다.
    보통 완전히 종속적인 경우 엔티티의 라이프사이클이 똑같아 등록, 삭제등의 과정을 함께 진행해도 문제가 되지 않는다.
  2. 소유자가 하나일 때 사용이 추천된다.
    예시에서는 parent만이 child를 소유할 때 cascade 사용이 추천된다. 만약 Member 등 다른 엔티티에서 child랑 관계가 있다면 사용하면 안된다.

고아 객체

  • 부모 엔티티와 연관관계가 끊어진 자식 엔티티를 자동으로 삭제하는 기능을 고아 객체(ORPHAN) 제거라 한다.
    • 부모 엔티티의 컬렉션에서 자식 엔티티의 참조만 제거하면 자식 엔티티가 자동으로 삭제되도록 만들 수 있다.
  • orphanRemoval = true 설정을 추가한다.
  • parent1.getChildList().remove(0); 코드를 통해 자식 엔티티를 컬렉션에서 제거하는 경우, DELETE FROM CHILD WHERE ID=? 쿼리가 실행된다.

설정: Parent

@Entity
public class Parent {

	// ...
    @OneToMany(mappedBy = "parent", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Child> childList = new ArrayList<>();

}

예시 코드

Parent findParent = em.find(Parent.class, parent.getId());
findParent.getChildList().remove(0);

실행되는 sql

DELETE FROM child WHERE id = ?

주의사항!

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

Parent parent = new Parent();
parent.addChild(child1);
parent.addChild(child2);

em.persist(parent);
em.persist(child1);
em.persist(child2);

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

Parent findParent = em.find(Parent.class, parent.getId());
em.remove(findParent);

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

  • CasecadeType.ALL + orphanRemoval = true
  • 스스로 생명주기를 관리하는 엔티티는 em.persist()로 영속화, em.remove()로 제거
    • 위 예시에서 parent의 생명주기는 jap가 관리하고 있다.
  • 두 옵션을 모두 활성화하면 부모 엔티티를 통해서 자식의 생명 주기를 관리할 수 있음.
    • 위 예시에서 child의 생명주기는 parent를 통해 관리하고 있다.
    • DB 개념으로 언급하자면 DAO나 리포지토리가 필요없게 된다.
  • 도메인 주도 설계(DDD)의 Aggregate Root 개념을 구현할 때 유용하다.
    • respository는 어그리게이트 루트만 컨택하고 나머지는 respository를 만들지 않고, aggregate 루트가 관리하는 하위 엔티티들은 aggregate 루트를 통해 생명주기를 관리해야 한다. 이 Aggregate Root 개념을 적용시킬때 영속성 전이와 고아 객체를 함께 사용해 적용해볼 수 있다.

Reference

profile
bien
Good Luck!
이전 포스트

[JPA] 자바 ORM 표준 JPA 프로그래밍 - 기본편 #7. 고급 매핑

0개의 댓글