[JPA 프로그래밍 기본기 다지기] JPA 내부구조 노트

2021-05-29글

영속성 컨텍스트

• 엔티티를 영구히 저장하는 환경
• 영속성 = 영구히 저장하는 속성
• 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 프로그래밍 기본기 다지기