Spring Boot JPA 영속성 컨텍스트

영속성 컨텍스트

엔티티를 영구적으로 저장하는 환경이라는 뜻이다.

애플리케이션과 데이터베이스 사이에서 객체를 보관하는 가상의 데이터베이스 역할을 한다.

 

EntiyManagerFacotry & EntityManager

JPA는 스레드가 하나 생성될 때 마다 EntitiymanagerFactory에서 EntityManager를 생성한다.

생성된 EntityManager는 내부적으로 DB 커넥션 풀을 사용해서 DB와 연결한다.

 

Spring 에서 EntityManager를 주입받아서 쓰면 같은 트랙잭션 범위에 있는 EntityManager는 동일한 영속성 컨텍스트에 접근한다.

 

 

비영속(New / transient)

• 영속성 컨텍스트와 전혀 관계가 없는 상태

// 객체를 생성만 한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

영속(Managed)

• 영속성 컨텍스트에 저장된 상태
• 엔티티가 영속성 컨텍스트에 의해 관리된다.
• 이때 DB에 저장 되지 않는다. 영속 상태가 된다고 DB에 쿼리가 날라가지 않는다.
• 트랜잭션의 커밋 시점에 영속성 컨텍스트에 있는 정보들이 DB에 쿼리로 날라간다. 

// 객체를 생성한 상태(비영속)
Member member = new Member();
member.setId("member1");
member.setUsername("회원1");

EntityManager em = emf.createEntityManager();
em.getTransaction().begin();

// 객체를 저장한 상태(영속)
em.persist(member);

준영속(detached)

• 영속성 컨텍스트에 저장되었다가 분리된 상태

// 회원 엔티티를 영속성 컨텍스트에서 분리, 준영속 상태
em.detach(member);

삭제(removed)

• 삭제된 상태. DB에서도 날린다.

// 객체를 삭제한 상태
em.remove(member);

 

영속성 컨텍스트의 이점

1차 캐시

영속성 컨텍스트 내부에는 1차 캐시가 존재하고 있는데 엔티티를 해당 영속성 컨텍스트에 저장하게 될 경우

• 1차 캐시의 key 값은 Entity의 @Id로 선언한 필드 값
• 1차 캐시의 value 값은 Entity 자체로 캐시에 저장된다.

해당 1차 캐시는 글로벌하지 않으며, 해당 스레드 하나가 시작할 때부터 끝날 때까지 잠깐 사용할 수 있고 다른 스레드와 공유하지 않는 캐시이다.

• 따라서 요청의 수 만큼 Entity manger가 생기고 1차 캐시도 생기게 되고 스레드가 종료될 경우 다 사라지게 된다.

이러한 1차 캐시가 있을 경우 Entity를 찾을 경우 DB에서 데이터를 먼저 찾는 것이 아니라 Entitiy Manager 내부의 1차 캐시에서 먼저 찾기 때문에 빠르게 값을 반환할 수 있다.

• 1차 캐시에 데이터가 없다면 DB에서 조회 → 해당 데이터(A)를 1차 캐시에 저장
• A를 조회할 경우 DB 조회가 아닌 1차 캐시에서 데이터(A) 반환

 

트랜잭션을 지원하는 쓰기 지연 - 엔티티 등록

• 트랜잭션 내부에서 persist()가 일어날 때 DB에 바로 넣지않고 Entity들을 1차 캐시에 저장하고, 논리적으로 쓰기 지연 SQL 저장소라는 곳에 INSERT Query들을 생성해서 쌓아 놓는다.
• commit()을 하는 시점에 DB에 동시에 해당 쿼리들을 보낸다. 이것을 flushI()라고 한다.
• flush()는 1차 캐시를 지우지 않고, 쿼리들을 DB에 날려서 DB와 싱크를 맞추는 역할을 한다. 해당 쿼리들을 보내고 나서 commit()을 한다.
• 따라서 트랜잭션을 커밋을 하는 것은 flush(), commit() 두 가지 일을 하는 것이다.

EntityManager em = emf.createEntityManager();
EntityTransaction transaction = em.getTransaction();
// 엔티티 매니저는 데이터 변경시 트랜잭션을 시작해야 한다.
transaction.begin(); // 트랜잭션 시작

em.persist(memberA);
em.persist(memberB);
// 이때까지 INSERT SQL을 데이터베이스에 보내지 않는다.

// 커밋하는 순간 데이터베이스에 INSERT SQL을 보낸다.
transaction.commit(); // 트랜잭션 커밋

 

변경 감지(Dirty Checking) - 엔티티 수정

@Transaction
public class void updateMember() {
	Member member = memberRepository.findById(1);
	member.setUserId("id");
	member.setUsername("웅");
}

위의 코드로 Entity가 수정이 되는데 해당 코드에는 persist나 save가 사용되지 않았는데 왜 저장이 되었을까??

• 이것을 변경 감지(Dirty Checking)이라고 한다.

• 1차 캐시에 Entity를 저장할 때 동시에 스냅샷에도 같은 내용의 Entity가 저장이 된다.
• 이때 commit() 또는 flush()가 일어날 때 1차 캐시에 있는 Entity와 스탭샷을 비교해서 변경사항이 있을 경우 UPDATE Query를 만들어서 저장해준다.

 

플러시란?

• 플러시는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다.
• 트랜잭션 커밋이 일어날 때 플러시가 동작하는데, 쓰기 지연 저장소에 쌓아 놨던 INSERT, UPDATE, DELETE SQL들이 데이터베이스에 날라간다.
• 쉽게 얘기해서 영속성 컨텍스트의 변경 사항들과 데이터베이스를 싱크하는 작업이다.

플러시 발생

• 플러시가 발생하면 변경을 감지한다. Dirty Checking.
• 수정된 엔티티를 쓰기 지연 SQL 저장소에 등록한다.
• 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송한다.(등록, 수정, 삭제 SQL)
• 플러시가 발생한 다고 커밋이 이루어지는게 아니고, 플러시 다음에 커밋이 일어난다.

영속성 컨텍스트를 Flush 하는 방법

• em.flush() 로 직접호출

// 영속
Member member = new Member(200L, "A");
em.persist(member);

em.flush();

System.out.println("플러시 직접 호출하면 쿼리가 커밋 전 플러시 호출 시점에 나감");

transaction.commit();

 

• 트랜잭션 커밋시 플러시 자동 호출
• JPQL 쿼리 실행하면 플러시 자동 호출
  • JPQL 쿼리 실행시 플러시가 자동으로 호출되는 이유는
  • 아래와 같이 member1,2,3을 영속화한 상태에서. 쿼리는 안날라간 상태
  • JPQL로 SELECT 쿼리를 날리려고 하면 저장되어 있는 값이 없어서 문제가 생길 수 있다.
  • JPA는 이런 상황을 방지하고자 JPQL 실행 전에 무조건 flush()로 DB와의 싱크를 맞춘 다음에 JPQL 쿼리를 날리도록 설정 되어 있다.
  • 그래서 아래의 상황에서는 JPQL로 멤버들을 조회할 수 있다.
  • em.persist(memberA); em.persist(memberA); em.persist(memberA); // 중간에 JPQL 실행 query = em.createQuery("select m from Member m", Member.class); List<Member> members = query.getResultList();
• 플러시가 일어나면 1차 캐시가 삭제될까?
  • 삭제 되지 않는다. 쓰기 지연 SQL 저장소에 있는 쿼리들만 DB에 전송되고 1차 캐시는 남아있다.

플러시 모드 옵션

• em.setFlushMode(FlushModeType.COMMIT);
  • FlushModeType.AUTO
    • 커밋이나 쿼리를 실행할 때 플러시(기본값)
  • FlushModeType.COMMIT
    • 커밋 할때만 플러시

플러시 정리

• 플러시는 영속성 컨텍스트를 비우지 않고 변경 되는 내용이 있을 경우 DB와 동기화하는 것이다.
• 플러시가 동작할 수 있는 이유는 데이터베이스 트랜잭션이라는 작업 단위(개념)가 있기 때문이다.
• 어쨋든 트랜잭션이 시작되고 커밋되는 시점에만 동기화 해주면 되기 때문에, 그 사이에서 플러시 매커니즘의 동작이 가능한 것이다.
• JPA는 기본적으로 데이터를 맞추거나 동시성에 관련된 것들은 데이터베이스 트랜잭션에 위임한다. 참고로 알아두자.

준영속 상태

• 영속 상태
  • 영속성 컨텍스트의 1차 캐시에 올라간 상태가 영속 상태이다. → 엔티티 매니저가 관리하는 상태.
  • 코드로 보면
    • em.find()가 일어 날때, 1차 캐시에 없으므로 DB에서 조회한 엔티티를 1차 캐시에 넣는다. 영속상태가 됐다.
    • setName으로 이름을 바꾸고 커밋 하려니까, Dirty Checking이 일어나서 1차 캐시의 엔티티와 스냅샷이 다른 것을 감지하고 Update 쿼리를 날리게 된다.

    Member member = em.find(Member.class, 150L);
    
    member.setName("AAAAA");
    transaction.commit();
    

• 준영속 상태 - 영속 상태의 엔티티가 영속성 컨텍스트에서 분리된 상태(detached)
  • em.detach(member); 로 멤버를 영속성 컨텍스트에서 분리하고
  • 트랜잭션을 커밋하면, 아무 일도 일어나지 않는다. JPA가 관리 하지 않는 객체가 된다.
  • 실제로 아래에선 UPDATE 쿼리가 나가지 않는다.
  • Member member = em.find(Member.class, 150L); member.setName("AAAAA"); em.detach(member); transaction.commit();
• 영속성 컨텍스트가 제공하는 기능을 사용하지 못함. 쿼리 안나감.
• 준영속 상태로 만드는 방법
  • em.detach(entity) - 특정 엔티티만 준영속 상태로 전환
  • em.clear() - 영속성 컨텍스트를 완전히 초기화
    • 아래 코드의 경우 첫번째 find에서 멤버를 SELECT 해서 영속성 컨텍스트에 저장하고
    • 영속성 컨텍스트를 초기화 했다.
    • 그러고나서 같은 아이디를 가지는 멤버를 다시 조회했을때는 SELECT 쿼리가 다시 나간다.
    • 총 2번의 SELECT 쿼리가 발생한다.
    • clear는 테스트 케이스 작성시에 도움이 된다.

    Member member = em.find(Member.class, 150L);
    member.setName("AAAAA");
    
    em.clear();
    
    Member member1 = em.find(Member.class, 150L);
    
    transaction.commit();
    

  • em.close() - 영속성 컨텍스트를 종료

 

 

 

 

 

영속성 컨텍스트에 대해서 너무 잘 정리해서 대부분 가져왔다..

 

출처

- https://ict-nroo.tistory.com/130

•