[JPA] 영속성 컨텍스트의 동작원리와 이점

🤭 미리 읽고 오면 좋은 글

[JPA] JPA, Hibernate, Spring Data JPA에 대한 이런저런.. 정리

[JPA] Hibernate JPA EntityManager 핵심 기능

---

1️⃣ 영속성 컨텍스트란?

영속성 컨텍스트는 엔티티를 영구 저장하는 환경을 뜻하며 애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 같은 역할을 한다. 엔티티 매니저를 통해 엔티티를 저장하거나 조회하면 엔티티 매니저는 영속성 컨텍스트 한 개를 만들어 엔티티를 보관하고 관리한다.

em.persist(member); // "엔티티 매니저를 이용해 회원 엔티티를 영속성 컨텍스트에 저장한다"는 의미

 

2️⃣ 영속성 컨텍스트의 동작원리

🌱 member 엔티티를 추가하는 과정

1. 엔티티가 영속화(persist)되어 1차 캐시에 저장된다.

2. 쓰기지연 SQL 저장소에 INSERT문이 생성되어 1차 캐시에 등록된 데이터를 DB 테이블에 추가할 준비를 한다.

3. flush 명령 시 쓰기지연 SQL 저장소에 저장되어 있던 쿼리들이 실행되면서 1차 캐시와 DB가 동기화된다.

4. 마지막으로 commit까지 완료되면 1차 캐시의 내용이 완전히 DB에 반영된다.

 

위 작업은 모두 단일한 트랜잭션 내에서 일어난다.

영속성 컨텍스트란 트랜잭션 내에서 일어나는 작업을 모두 기록하는 공간이며, 모든 작업은 언제든 ROLLBACK 될 수 있다.

 

3️⃣ 영속성 컨텍스트 범위

트랜잭션이 같으면, 같은 영속성 컨텍스트를 사용한다.

 

트랜잭션 범위의 영속성 컨텍스트 전략은 다양한 위치에서 엔티티 매니저를 주입받아 사용하더라도, 동일한 트랜잭션 내에서는 항상 같은 영속성 컨텍스트를 사용한다.

@Repository
class Repo1 {
    @PersistenceContext EntityManager em;
    
    public void logic1(){
    	em.xxx(); // Repo1의 영속성 컨텍스트 접근
    }
}


@Repository
class Repo2 {
    @PersistenceContext EntityManager em;
    
    public void logic2(){
    	em.xxx(); // Repo2의 영속성 컨텍스트 접근
    }
}

 

위와 같은 상황에서 아래 logic()을 실행하는 상황을 예로 들면

@Service
class MainService{
    @Autowired Repo1 repo1;
    @Autowired Repo2 repo2;
    
    @Transctional
    public void logic(){
    	repo1.logic1();
        repo2.logic2(); 
    }
}

 

repo1과 repo2의 엔티티 매니저는 다르지만, 같은 트랜잭션이기 때문에 같은 영속성 컨텍스트를 사용한다.

 

그리고 해당 영속성 컨텍스트는 트랜잭션과 생명주기가 동일하다.

---

트랜잭션이 다르면, 다른 영속성 컨텍스트를 사용한다.

스프링 컨테이너는 스레드마다 각각 다른 트랜잭션을 할당하기 때문에 같은 엔티티 매니저를 사용해도 다른 영속성 컨텍스트를 사용한다.

따라서 영속성 컨텍스트가 스레드 간에 공유되지 않으므로 멀티스레드 상황에 안전하다.

 

4️⃣ 영속성 컨텍스트의 이점

• 1차 캐시
• 동일성 보장
• 변경 감지(Dirty Checking)
• 쓰기 지연
• 지연 로딩

1) 1차 캐시

🌱 member 엔티티를 조회하는 과정

1. EntityManager가 조회(find)를 요청한다.

2. 1차 캐시에서 우선적으로 데이터를 찾고 원하는 데이터가 없는 경우 DB SELECT문을 실행하여 조회한다.

3. 조회한 결과를 1차 캐시에 저장하고 엔티티 객체를 생성하여 반환(return)한다.

 

이후 단일 트랜잭션에서 같은 엔티티를 조회할 경우 1차 캐시에서 바로 엔티티 조회가 가능하다.

이는 데이터베이스 접근을 줄여 성능을 향상시킨다.

 

2) 동일성 보장

1차 캐시는 flush가 수행되지 않는 이상 DB와 동기화되지 않는다. 따라서 1차 캐시에 존재하는 엔티티는 언제나 동일한 엔티티이다.

Member findMember1 = em.find(Member.class, 10L);
Member findMember2 = em.find(Member.class, 10L);

System.out.println("findMember = " + (findMember1 == findMember2));

 

따라서 같은 트랜잭션 안에서 == 비교 시 동일한 참조가 나와 true를 반환한다.

 

3) 쓰기 지연

위의 영속성 컨텍스트의 동작 원리에서 설명했듯이 영속성 컨텍스트는 쓰기지연 SQL 저장소를 가져 SQL문이 생성되어도 바로 실행되지 않고 저장된다. 따라서 잦은 I/O 발생을 막을 수 있다.

또, 원하는 시점에 개발자가 SQL문을 실행할 수 있도록 flush 기능을 제공한다.

 

🤔 flush가 호출되는 경우

1. entitymanager.flush(): 개발자가 직접 호출
2. tx.commit(): 자동 실행
   • 커밋 전 저장소에 있는 SQL문들을 flush 하여 실행시킨 후, DB에 반영한다.
3. JPQL 쿼리 실행: 자동 실행
   • JPQL은 JPA 맞춤 SQL 쿼리문이다. JPQL은 EntityManager가 실행하는 쿼리로 파싱 되어 SQL문으로 변환되어 쓰기지연 SQL 저장소에 저장되지 않고 바로 DB에 실행된다.
     따라서 이전에 쓰기지연 SQL 저장소에 저장했던 SQL문들을 먼저 flush 해야 데이터에 문제가 생기지 않는다.

 

4) 변경 감지(Dirty Checking)

영속성 컨텍스트는 1차 캐시에 저장된 엔티티의 처음 상태를 스냅샷으로 만들어 저장한다.

 

🌱 member 엔티티를 수정하는 과정

1. 개발자가 find()로 엔티티를 조회한다.

2. 개발자가 해당 엔티티를 setter 함수로 필드 데이터를 변경했다.

❗️ 처음 상태의 스냅샷과 동일했던 과거와 달리, 더럽혀졌다.(Dirty)

 

영속성 컨텍스트는 초기 상태를 저장한 스냅샷과 엔티티를 비교하여 얼마나 더러워졌는지를 체크하는데, 이를 Dirty Checking 즉, 변경감지라 부른다.

변경이 감지되면 영속성 컨텍스트는 자동으로 UPDATE문을 생성하여 쓰기지연 SQL 저장소에 저장한다.

개발자는 단순히 필드 데이터만 변경한 것인데 자동으로 UPDATE문까지 생성되어 손쉬운 개발이 가능해진다.

 

5) 지연 로딩(Lazy Loading)

🌱 즉시 로딩(Eager Loading)

연관 관계 매핑의 fetch 속성을 FetchType.EAGER로 지정해 엔티티 조회 시 연관된 엔티티를 함께 조회한다.

 

public class Member {
    ...
    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "TEAM_ID")    
    private Team team;
}

SELECT 
	...
FROM 
	MEMBER M LEFT OUTER JOIN TEAM T
		ON M.TEAM_ID=T.TEAM_ID
WHERE
	M.MEMBER_ID="id"

 

하이버네이트는 즉시 로딩을 최적화하기 위해 가능하면 조인 쿼리를 통해 연관 엔티티를 한 번에 조회한다.

이때, 실행되는 SQL은 외부 조인(LEFT OUTER JOIN)을 사용한다. (회원은 팀이 없을 수 있어 NULL값을 허용하기 때문)

 

하지만 성능 최적화에서는 내부 조인(INNER JOIN)이 유리하기 때문에 @JoinColumn(nullable = false)를 사용하면 내부 조인을 사용할 수 있다.

 

🌱 지연 로딩(Lazy Loading)

연관 관계 매핑의 fetch 속성을 FetchType.LAZY로 지정해 연관된 엔티티를 실제로 사용할 때 조회한다.

 

@Entity
public class Member {
    ...
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "TEAM_ID")    
    private Team team;
}

 

회원 조회 시 바로 팀을 조회하지 않고, team 멤버 변수에 프록시 객체(가짜 객체)를 넣어둔다.

그 후 team의 실제 데이터가 필요한 순간에 DB를 조회해 프록시 객체를 조회한다.

만약 영속성 컨텍스트에 객체가 이미 존재할 경우 프록시 객체가 아닌 실제 객체를 사용한다.

 

추천하는 방법은 모든 연관관계에 지연 로딩을 사용하는 것이지만 지연 로딩이 항상 좋은 것은 아니다.

만약 팀과 회원을 항상 함께 사용한다면 처음부터 한 번에 가져오는 것이 효율적이기 때문에 상황에 맞게 선택하는 것이 좋다.

따라서 개발 완료 단계에 왔을 때, 실제 사용 상황을 보며 최적화하는 것이 좋다.

 

 

 

 

[JPA] 프록시, 즉시 로딩과 지연로딩

[JPA] 영속성 컨텍스트의 이점 ( + DirtyChecking )

[JPA] OSIV 란?

트랜잭션 범위의 영속성 컨텍스트