Spring boot, JPA (2) - 영속성 컨텍스트(Persistence Context)

영속성 컨텍스트(Persistence Context)

• 1차 캐시를 통한 성능 최적화

• 동일성(identity) 보장

• 변경 감지(Dirty Checking)

• 지연 로딩(Lazy Loading)

• 쓰기 지연(Transactional Write-Behind)

class PersistenceContext {
    Map<EntityId, Entity> cache;              // 엔티티 저장소
    Map<EntityId, EntitySnapshot> snapshot;   // 스냅샷 - 최초 상태
    Map<Entity, List<SQL>> sqlLog;           // 쓰기 지연 SQL 저장소
}

1차 캐시

Spring boot, JPA (3) - 1차 캐시 - vlogue

1차 캐시와 2차 캐시 등, JPA Cache 사용법 | Java & Spring Boot, DB, Java & JPA &Hibernate

https://inblog.ai/vlogue/36939?traffic_type=internal

동일성 보장(Identity)

// 최초 DB 조회 => 1차 캐시 등록
Member member1 = em.find(Member.class, "id1");

// 두 번째 조회 => 1차 캐시 조회
Member member2 = em.find(Member.class, "id1");

System.out.println(member1 == member2); // true

• 영속성 컨텍스트가 1차 캐시에 엔티티를 보관할 때 ID를 키로 사용

• 같은 ID로 조회 시 새로운 객체를 생성하지 않고 기존 캐시된 인스턴스를 반환

• 따라서 같은 영속성 컨텍스트 안에서는 동일한 ID의 엔티티는 항상 같은 인스턴스

다양한 동일성 보장 예시

• 다른 영속성 컨텍스트에서는 동일성이 보장되지 않습니다.

EntityManager em1 = emf.createEntityManager();
EntityManager em2 = emf.createEntityManager();

Member member1 = em1.find(Member.class, "id1");
Member member2 = em2.find(Member.class, "id1");

System.out.println(member1 == member2); // false

• JPQL을 사용하는 경우에도 동일성이 보장됩니다.

@Service
public class MemberService {
    private final MemberRepository memberRepository;
    @PersistenceContext
    private EntityManager em;

    public void example() {
        // 각각의 조회가 별도의 트랜잭션으로 실행될 수 있음
        Member member1 = em.find(Member.class, "id1");
        Member member2 = em.createQuery(...)
        Member member3 = memberRepository.findById("id1").get();

        // false가 나올 수 있음
        System.out.println(member1 == member2); // true
        System.out.println(member2 == member3); // true
        System.out.println(member1 == member3); // false
    }
}

@Service
@Transactional  // 하나의 트랜잭션으로 묶임
public class MemberService {
    private final MemberRepository memberRepository;
    @PersistenceContext
    private EntityManager em;

    public void example() {
        Member member1 = em.find(Member.class, "id1");
        Member member2 = em.createQuery(...)
        Member member3 = memberRepository.findById("id1").get();

        System.out.println(member1 == member2); // true
        System.out.println(member2 == member3); // true
        System.out.println(member1 == member3); // true
    }
}

• 영속 상태가 된 엔티티는 항상 동일성 보장
여기서 영속 상태란, 엔티티가 영속성 컨텍스트내의 엔티티로 등록 됐다는 것으로 1차 캐시에 등록됐다는 것과 같은 의미합니다.

Member newMember = new Member("id1", "kim");
em.persist(newMember);  // 영속화

Member findMember = em.find(Member.class, "id1");
System.out.println(newMember == findMember); // true

• 연관관계를 통한 조회시에도 동일성 보장

// Order에서 Member 참조
Order order = em.find(Order.class, 1L);
Member member1 = order.getMember();

// 직접 Member 조회
Member member2 = em.find(Member.class, member1.getId());

System.out.println(member1 == member2); // true

• 엔티티 변경 후 flush / execute / commit 후 조회시 동일성이 깨질 수 있음

Member member = em.find(Member.class, "id1");
System.out.println(member.getName()); // "kim"

// 벌크 연산 수행
em.createQuery("update Member m set m.name = 'lee' where m.id = :id")
  .setParameter("id", "id1")
  .executeUpdate(); // DB 반영

// 1차 캐시는 여전히 이전 데이터 상태
System.out.println(member.getName()); // "kim"

// 다시 조회해도 1차 캐시에 있는 값을 반환
Member member2 = em.find(Member.class, "id1");
System.out.println(member2.getName()); // "kim"
System.out.println(member == member2); // true

// 영속성 컨텍스트 초기화 후 조회해야 새로운 값이 반영됨
em.clear();
Member member3 = em.find(Member.class, "id1");
System.out.println(member3.getName()); // "lee"
System.out.println(member == member3); // false

• 병합(merge) 사용시 동일성

// 준영속 상태의 엔티티
Member detached = new Member("id1", "kim");

// 병합으로 영속 상태로 변경
Member merged = em.merge(detached);

// 다시 조회
Member found = em.find(Member.class, "id1");

System.out.println(detached == merged); // false
System.out.println(merged == found);    // true

변경 감지(Dirty Checking)

@Transactional
public void updateMember() {

    Member member = em.find(Member.class, "id1");
    
    member.setName("newName");    // 변경 감지 동작
    member.setAge(32);           // 변경 감지 동작
    
    // em.update() 이런 코드가 없어도 @Transactional이 자동으로 변경 감지 동작
}

1. 트랜잭션 커밋 시점에, Entity Manager 내부에서 flush 호출

2. 기존 엔티티와 스냅샷(최초 캐시로 등록된 엔티티)을 비교

3. 변경된 엔티티가 있으면 UPDATE SQL 생성

4. 쓰기 지연 SQL 저장소에 UPDATE SQL 등록

5. DB에 SQL 반영

em.detach(member);
member.setName("newName");    // 변경 감지 동작 안함

public void updateMember() {  // @Transactional 없음
    Member member = em.find(Member.class, "id1");
    member.setName("newName"); // 변경이 DB에 반영되지 않을 수 있음
}

@Entity
@DynamicUpdate
public class Member {
    @Id
    private String id;
    private String name;
    private Integer age;
}

지연 로딩(Lazy Loading)

// Member 조회 - 이때는 Team 정보를 조회하지 않음
Member member = em.find(Member.class, "id1");

// Team 정보가 실제로 필요한 시점에 쿼리 실행
String teamName = member.getTeam().getName();

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "customer_id")
private Team team;

• Lazy (지연 로딩)
• Lazy 이 설정은 연관된 엔티티를 실제로 필요할 때까지 로드하지 않도록 합니다. 즉, 부모 엔티티를 조회할 때 자식 엔티티는 즉시 로드되지 않고, 해당 자식 엔티티에 접근할 때 쿼리가 실행되어 로드됩니다.
• 즉, 필요할 때만 로드합니다.
• 간혹가다 Lazy loading not working 이라는 키워드를 발견할 수 있는데, 제목과 같은 에러가 발생했다면 Lazy loading이 적용 중인 걸로 생각해주시면 됩니다.

• Eager (즉시 로딩)
• 이 설정은 부모 엔티티를 조회할 때 연관된 자식 엔티티도 즉시 로드하도록 합니다. 즉, 부모 엔티티를 가져오는 쿼리와 함께 자식 엔티티를 가져오는 쿼리가 동시에 실행됩니다.
•  연관된 데이터를 항상 필요로 할 때 유용하지만, 불필요한 데이터 로드를 초래할 수 있어 성능 저하를 일으킬 수 있습니다.
• 즉, 항상 로드합니다.

1. 예를 들어 Member 10명을 조회하는 상황

2. 각 Member는 Team과 연결되어 있고, 지연로딩으로 설정

List<Member> members = memberRepository.findAll(); // Member 10명 조회 -> 1번의 쿼리

for(Member member : members) {
    System.out.println(member.getTeam().getName()); // 각 멤버마다 Team 조회 쿼리 발생 -> 10번의 쿼리
}

Spring boot, JPA could not initialize proxy - no Session - vlogue

closing the session or not keeping the session open to fetch the LAZY loaded objects. | Etc., Java & Spring Boot, System/Network, Error, DB, Java & JPA &Hibernate

https://inblog.ai/vlogue/spring-boot-jpa-could-not-initialize-proxy-no-session-30234?traffic_type=internal

쓰기 지연(Transactional Write-Behind)

@Transactional
public void saveMembers() {
    // 1. 첫번째 저장
    Member member1 = new Member("member1");
    em.persist(member1);    // INSERT SQL을 데이터베이스에 보내지 않음
    
    // 2. 두번째 저장
    Member member2 = new Member("member2");
    em.persist(member2);    // INSERT SQL을 데이터베이스에 보내지 않음
    
    // 여기까지 INSERT SQL을 데이터베이스에 보내지 않음
    
    // 트랜잭션 커밋
    // 이때 모아둔 INSERT SQL을 데이터베이스에 보냄
}

1. em.persist()를 호출하면 엔티티를 영속성 컨텍스트에 저장

2. 이때 INSERT SQL을 생성해서 쓰기 지연 SQL 저장소에 보관

3. 트랜잭션 커밋 시점에 쓰기 지연 SQL 저장소에 모인 쿼리들을 데이터베이스에 보냄