📋 Jpa - 양방향 매핑

양방향 매핑

• 반대방향으로도 그래프 조회가 가능해야함

연관 관계의 주인과

• 왜 mappedBy를 해주는 건지?

• 객체는 서로를 포함하고 있어야 함 (2개가 필요)

객체와 테이블이 관계를 맺는 차이

객체 연관관계

• 회원 -> 팀 연관 관계 1개 (단방향)
• 팀 -> 회원 연관관계 1개 (단방향)

테이블 연관관계

• 회원 <-> 팀의 연관관계 1개 (양방향)

이 차이를 어떻게 극복할거냐??

객체의 양방향 관계

객체는 사실 양방향 관계가 아니라 서로 다른 단방향 관계 2개이다.
객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 함

테이블의 양방향 관계

테이블은 외래키 하나로 두테이블의 연관 관계를 관리

둘 중 하나로 외래키를 관리해야 한다

• 객체는 두 곳에서 연관관계에 있는 객체를 다루고 있음
• 그러면 뭘 믿어야 하나?
• 두개는 어차피 다르다. 둘 중 하나만 주인으로 만들자

연관 관계의 주인

• 두곳에 있는 객체중 하나만 주인으로 두고 걔만 영향을 받음

양방향 매핑 규칙

• 객체의 두 관계 중 하나를 연관관계의 주인으로 지정
• 연관관계의 주인만이 외래키를 관리(등록, 수정)
• 주인이 아닌 쪽은 읽기만 가능
• 주인은 mappedBy 속성 사용 x
• 주인이 아니면 mappedBy 속성으로 주인 지정

그런데 누구를 주인으로 해야하나?

• 외래키가 있는 곳을 주인으로 정해라
• 여기서는 Member.team이 연관관계의 주인

참고 - 설계

• 일단 단방향으로 다 설계를 하고 양방향이 필요할 때 양방향을 추가하자
• 양방향은 조회를 편하게 하기 위해 사용하는 느낌
• 인지 부조화가 생기지 않음

양방향 매핑시 가장 많이 하는 실수

• 연관관계의 주인에 값을 입력하지 않음

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

Member member = new Member();
member.setName("amazzi");
member.setTeam(team);
em.persist(member);

• 주인에 값을 입력하기

양방향 매핑시 연관관계의 주인에 값을 입력해야함

• 순수한 객체 관계를 고려하면 항상 양쪽 다 값을 입력해야 함

• 실제 코드에는 양쪽 다 할 것을 권장

양방향 매핑의 장점

• 단방향 매핑만으로도 이미 연관관계 매핑은 완료
• 양방향 매핑은 반대 방향으로 조회(객체 그래프 탐색) 기능이 추가된 것 뿐
• JPQL에서 역방향으로 탐색할 일이 많음
• 단방향 매핑을 잘하고 양방향은 필요할 때 추가해도 됨(테이블에 영향을 주지 않음)

연관 관계 매핑 어노테이션

• 다대일 @ManyToOne
• 일대다 @OneToMany
• 일대일 @OneToOne
• 다대다 @ManyToMany
• @JoinColum, @JoinTable

상속 관계 매핑 어노테이션

• @Ingeritance
• @DiscriminatorColumn
• @DiscriminatorValue
• @MappedSuperclass : 매핑 속성만 상속

복합키 어노테이션

• @IdClass
• @EmbeddeId
• @Embeddable
• @MapsId

JPA 내부구조

영속성 컨텍스트

• 엔티티를 영구히 저장하는 환경
• 영속성 = 영구히 저장하는 속성
• EntityManager.persist(entity)
• 영속성 컨텍스트는 논리적인 개념 (눈에 보이지 않음)
• 엔티티 매니저를 통해 영속성 컨텍스트에 접근

스프링 프레임 워크에서의 영속성 컨텍스트

• 엔티티 매니저와 영속성 컨텍스트가 N:1
• 같은 트랜잭션이면 같은 영속성 컨텍스트에 접근

엔티티 매니저 팩토리와 엔티티 매니저

• 요청이 들어와 이걸 처리하는 스레드가 하나 생성될 때마다 새로운 엔티티 매니저를 만든다.

• 엔티티 매니저에서 내부적으로 데이터베이스 커넥션 풀에서 JPA를 사용

엔티티의 생명 주기

비영속 (New)

• 객체를 생성한 상태

Team team = new Team();
team.setName("teamA");

영속

• 비영속 상태인 객체를 영속성 컨텍스트에 저장한 상태
• 영속성 컨텍스트 안에서 관리되기 시작

em.persist(team);

준영속 (Detached)

• 엔티티를 영속성 컨텍스트에서 분리

em.detach(team);

• 영속 -> 준영속
• 영속 상태의 엔티티가 영속성 컨텍스트에서 분리
• 영속성 컨텍스트가 제공하는 기능을 사용 못함

준영속 상태로 만드는 방법

• em.detched(entity) : 특정 엔티티만 준영속 상태로 전환
• em.clear() : 영속성 컨텍스트를 완전히 초기화
• em.close() : 영속성 컨텍스트를 종료

삭제

• 객체를 삭제한 상태

em.remove(team);

영속성 컨텍스트의 이점

1차 캐시

• 엔티티 매니저 안에 키 밸류로 캐시가 됨

1차 캐시에서 조회

Member member = new Member();
member.setName("amazzi");
// 1차 캐시에 저장됨
em.persist(member);
// 1차 캐시에서 조회
Memeber findMember = em.find(Member.class, "member1");

• DB를 가지 않음
• 1차 캐시는 Global 캐시가 아님. 트랜잭션 안에서만 동작하는 캐시

데이터 베이스에서 조회

Member findMember2 = em.find(Member.classm "member2");

동일성 보장

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

a == b // 동일성 비교 true

• 1차 캐시로 반복 가능한 읽기 등급(REPEATABLE READ) 등급의 트랜잭션 격리 수준을 DB 가 아닌 애플리케이션 차원에서 제공

트랜잭션을 지원하는 쓰기 지연

em = entityManagerFactory.createEntityManager();
EntityTransaction transaction = em.getTransaction();
// 엔티티 매니저는 데이터 변경시 트랜잭션을 시작해야 함
transaction.begin();
try {
    em.persist(member1);
  	em.persist(member2);
    // 여기까지 INSERT 쿼리를 DB에 날리지 않음

    transaction.commit(); // 트랜잭션 커밋
    em.flush();
    em.clear();
} catch (Exception e) {
    transaction.rollback();
}

• 논리적인 개념. 이 때 Insert 쿼리를 쌓아 놓는다.

transcation.commit();

변경 감지(Dirty Checking)

em = entityManagerFactory.createEntityManager();
EntityTransaction transaction = em.getTransaction();
// 엔티티 매니저는 데이터 변경시 트랜잭션을 시작해야 함
transaction.begin();
try {
  	// 영속 엔티티 조회
    Member memberA = em.find(Member.class, "memberA");
  
    // 영속 엔티티 데이터 수정
  	memberA.setName("hi");
    
    transaction.commit(); // 트랜잭션 커밋
    em.flush(); // 쿼리를 다 날림
    em.clear(); // 영속성 컨텍스트 안에 있는 캐시를 다 날림
} catch (Exception e) {
    transaction.rollback();
}

• em.update(member) 이런 코드가 없어도 됨

• 1차 캐시가 생성되는 순간 스냅샷이 생긴다.
• JPA는 트랜잭션이 커밋되는 순간 스냅샷과 1차 캐시의 엔티티를 비교해서 바뀐 놈을 감지한다.
• 그래서 update 쿼리를 날림

왜 이렇게 했을까?

• 자바 컬렉션에서 데이터를 가져오고 이를 변경하면 리스트에 있는 값이 바뀌죠?
• 이거랑 같은 맥락
• 그래서 바꾸고 커밋만 치면 된다.

엔티티 삭제

// 삭제 대산 엔티티 조회
Member memberA = em.find(Member.class, "memberA");
em.remove(memberA); // 엔티티 삭제

• 트랜잭션 커밋 시점에 쿼리가 날라감
• 버퍼를 최대한 늦춘다. (트랜잭션 커밋할 때까지)

플러시

• 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영

플러시가 발생될 때

• 변경 감지
• 수정된 엔티티 쓰기 지연 SQL 저장소에 등록
• 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송 (등록, 수정, 삭제 쿼리)

플러시하는 방법

• em.flush() : 직접 호출
• 트랜잭션 커밋 : 플러시 자동 호출
• JPQL 쿼리 실행 : 플러시 자동 호출

JPQL 쿼리 실행시 플러시가 자동으로 호출되는 이유

em.persist(memberA);
em.persist(memberB);
em.persist(memberC);

// 중간에 JPQL 실행 // 플러시가 먼저 수행된다.
query - em.createQuery("select m from Member m", Member.class);
List<Member> members = query.getResultList();

• 쿼리 실행 때 플러시가 안되면 DB에서 조회해올 수 없기 때문
• 만약 마이바티스나 JDBC를 사용하면 플러시가 안됨

플러시는!

• 영속성 컨텍스트를 비우지 않음
• 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화
• 트랜잭션이라는 작업 단위가 중요 -> 커밋 직전에만 동기화 하면 됨

지연 로딩(Lazy Loading)

지연로딩과 영속성 컨텍스트

• Member를 조회할 때 Team도 함께 조회해야 할까?
• 단순히 member 정보만 사용하는 비즈니스 로직이라면… 미리 조회할 필요가 없겠죠
  • member.getName()
  • 이러면 FetchType.Lazy로 지연로딩을 걸자

• Member를 조회할 때 Team은 가짜 객체(프록시 객체)가 들어감

즉시로딩

• FetchType.EAGER
• Member를 조회할 때 Team도 함께 조회

프록시와 즉시로딩 주의

• 가급적 지연 로딩을 사용
• 즉시 로딩을 적용하면 예상하지 못한 SQL이 발생
• 즉시 로딩은 JPQL에서 N+1 문제를 일으킴
• @ManyToOne, @OneToOne 은 기본이 즉시 로딩
  • LAZY로 설정하기
• @OneToMany, @ManyToMany 는 기본이 지연 로딩
• 스프링에서는 트랜잭션이 끝나고 컨트롤러에서 LAZY 로딩 하려고 할 때 문제 생김
  • Open Session In View
  • 와 이게 이제 와닿네

참고 자료

• [토크ON세미나] JPA 프로그래밍 기본기 다지기