영속성 관리 - 내부 동작 방식, 영속성 컨텍스트, 플러시, 준영속 상태

출처 : 인프런 - 자바 ORM 표준 JPA 프로그래밍 - 기본편(유료) / 김영한님  
유료 강의이므로 정리에 초점을 두고 코드는 일부만 인용

---

1. 영속성 컨텍스트

• JPA를 이해하는데 가장 중요한 용어
• 엔터티를 영구 저장하는 환경이라는 뜻
• EntityManager.persist(entity); -> DB에 저장하는 것이 아니라 엔터티를 영속성 컨텍스트에 저장한다는 뜻

1) 엔터티매니저, 영속성 컨텍스트

• 영속성 컨텍스는 논리적인 개념이기에 눈에 보이지 않으며 엔터티 매니저를 통해 영속성 컨텍스트에 접근함
• 엔터티 매니저를 생성하면 1:1로 영속성 컨텍스트가 생성된다고 이해하면 됨되며 스프링 프레임워크같은 컨테이너 환경에서는 엔터티매니저와 영속성 컨텍스트가 N:1로 생성됨

2) 엔터티의 생명주기

(1) 비영속 (new/transient)

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

(2) 영속 (managed)

• 영속성 컨텍스트에 관리되는 상태

(3) 준영속 (detached)

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

(4) 삭제 (removed)

• 삭제된 상태, 실제 DB에서 삭제

// 객체만 생성한 상태, JPA와 전혀 관계없는 상태 - 비영속
Member member = new Member();
member.setId(100L);
member.setUsername("HelloJPA");

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

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

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

3) 영속성 컨텍스트의 이점

• 1차 캐시
• 동일성(identity) 보장
• 트랜잭션을 지원하는 쓰기 지연(transactional write-behind)
• 변경 감지(Dirty Checking)
• 지연 로딩(Lazy Loading) - 이후 강의에서 별도로 다룸

(1) Entity 조회, 1차 캐시

• 영속성 컨텍스트는 내부에 1차 캐시라는 것을 들고 있는데 em.persist로 생성한 멤버를 집어 넣게 되면 pk로 맵핑한 값이 key가 되고 객체 자체가 value가 되어 DB에 저장하는 것이 아니라 1차캐시에 저장(Map 자료구조가 있다고 보면 됨)하고 DB에 저장하는 것은 트랜잭션 커밋을 해야만 DB에 반영됨
• 만약 이렇게 멤버 객체를 저장해놓고 조회를 하면 jpa는 1차 캐시에 조회할 대상이 있는지 찾고 없으면 DB에서 조회하여 값을 반환함
• jpa는 보통 트랜잭션 단위로 동작하는데 데이터베이스 트랜잭션이 끝날 때 1차 캐시는 같이 종료가 되어버리기 때문에 여러 요청이 사용하는 캐시는 아니고 해당 트랜잭션 안에서만 효과가 있음
• 이렇게 동작하는 방식이 비즈니스 로직이 굉장히 복잡한 경우에는 도움이 될 수도 있지만 성능 보다는 이러한 컨셉을 이래하면 객체 지향적으로 코드를 작성하는데 있어서 도움이 될 수 있음

좌) 조회할 값이 1차 캐시에있으므로 1차캐시에서 반환 / 우) 조회할 값이 1차 캐시에 없으므로 DB에서 찾아서 반환

• DB에 저장된 값을 2번 조회하면 select 문은 한번만 출력되지만 조회는 2번 되는 것을 확인할 수 있음

// DB에 id값이 104인 member가 있을때 이렇게 2번 조회하면
// select문은 1번만 나오지만 값은 2번찍힘

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

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

 

(2) 영속 엔터티의 동일성 보장

• 1차 캐시로 반복 가능한 읽기(REPEATABLE READ) 등급의 트랜잭션 격리 수준을 DB가 아닌애플리케이션 차원에서 제공함
• 쉽게 이야기해서 1차 캐시덕분에 같은 트랜잭션안에서 조회된 결과는 자바 컬렉션에서 조회한 것처럼 == 비교시 true가 나온다(같은 참조)는 뜻

Member findMember1 = em.find(Member.class, 104L);
Member findMember2 = em.find(Member.class, 104L);
// 자바 컬렉션에서 꺼내서 == 비교를 하면 true가 나오듯이, 마찬가지로 결과가 true가 됨
System.out.println("result = " + (findMember1 == findMember2));

 

(3) 엔터티 등록시 트랜잭션을 지원하는 쓰기 지연

• 여러번의 persist를 하면 각각 DB에 바로 반영되는 것이 아니라 1차 캐시에 반영하고 동시에 쓰기 지연 SQL 저장소에 생성된 SQL 쿼리를 호출한 persist만큼 모아두고 트랜잭션이 커밋이 되면 그때 모든 SQL문이 전송되면서 DB에 반영이 됨

persist를 하면 바로 DB에 저장되는 것이 아니라 commit을 해야 DB저장됨

Member member1 = new Member(120L, "A");
Member member2 = new Member(121L, "B");
em.persist(member1);
em.persist(member2);
System.out.println("==============================================");
tx.commit();

 

• 해당 코드의 실행 결과처럼, inset문이 persist가 호출된 직후가 아니라 print문으로 출력된 구분선 이후 commit이 동작하면서 insert문이 동작함
• 이렇게 버퍼에 모아두고 한번에 DB에 반영하면 최적화를 할 수 있는 여지가 있게 되는데 SQL을 직접 다뤄서 하는 것보다 훨씬 간편하게 할 수 있음 -> HTTP 요청의 횟수를 줄일 수 있음
• persistence.xml에 아래의 옵션을 작성하여 배치사이즈를 지정한 값만큼 persist를 보관해 두었다가 DB에 전송함
• 만약에 값이 1이거나 옵션을 지정하지 않으면 쓰기지연 SQL 저장소에 모아둔 SQL갯수만큼 네트워크 전송 횟수가 발생되지만 옵션을 지정하면 지정한 만큼 모아두었다가 한번에 쿼리를 DB에 보내기 때문에 네트워크 요청 횟수를 줄여 최적화를 할 수 있음

<property name="hibernate.jdbc.batch_size" value="10"/>

 

(4) 엔터티 수정, 변경감지(Drity Checking)

• JPA는 데이터베이스 트랜잭션을 커밋하는 시점에 내부적으로 플러쉬라는게 호출이 되고 1차캐시 안에는 아까 설명한 persist로 저장한 id와 엔터티 외에도 스냅샷이있는데 엔터티와 이스냅샷을 비교함
• 스냅샷은 최초에 영속성 컨텍스트에 들어온 엔터티의 상태를 스냅샷으로 떠두어서 보관해놓은 장소임
• 만약 DB에서 조회한 엔터티의 값을 변경하면 1차 캐시의 엔터티와 스냅샷을 내부의 최적화된 로직으로 비교하고 엔터티와 스냅샷이 다르면 변경되었다고 감지되어 persist없이 update 쿼리문을 생성하여 쓰기 지연 SQL 저장소에 저장하고 commit이 되면 쿼리를 데이터베이스에 반영함

 

• 아래처럼 persist없이 호출한 값을 수정하고 commit만해도 알아서 update문이 생성되어 DB에 반영됨

Member findMember = em.find(Member.class, 110L);
findMember.setName("zzzz");
tx.commit();

 

(5) 엔터티 삭제

• 조회한 엔터티를 remove()로 호출하면 마찬가지로 delete 쿼리를 쓰기 지연 SQL 저장소에 보관했다가 commit 시점에 DB에 전송함

Member findMember = em.find(Member.class, 110L);
em.remove(findMember);
tx.commit();

 

** JPA의 전체적인 동작은 위처럼 commit 시점에 실제 DB에 값이 반영되고, 값을 변경할 때는 내부적인 로직에 의해 알아서 update가 수행되기 때문에 값만 변경하면 되며, 이것이 영속성 컨텍스트의 이점임

---

2. 플러시

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

1) 플러시 발생

• 데이터베이스 트랜잭션이 커밋되면 플러시는 자동으로 발생됨
• 변경 감지(Dirty Checking) 발생
• 수정된 엔터티를 쓰기 지연 SQL 저장소에 등록하고 commit한 경우에 저장소의 SQL 쿼리를 데이터베이스에 전송
• 만약 em.flush()를 호출하면 commit전에도 DB에 SQL쿼리를 전송할 수 있음
• 플러시 즉시 호출 시 commit을 하지 않았으므로 DB에 영구적으로 데이터가 반영되는 것은 아닌 상태임 즉, 다른 커넥션으로 DB에서 값을 조회했을 때에는 플러시를 즉시 호출하여 DB에 반영한 내용은 보이지 않음

2) 영속성 컨텍스트를 플러시하는 방법

• 직접 쓸일은 거의 없으나 간혹 테스트 등에 쓰일 수 있으므로 알아 두는것이 좋음
• em.flush() - 직접 호출
• 트랜잭션 커밋, JPQL 쿼리 실행 - 플러시 자동 호출

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

• 여러번 persist를 호출하여 영속성 컨텍스트에는 엔터티를 보관했지만 commit을 하지않아 DB에 반영되기 전에 JPQL을 호출하여 DB의 값을 조회하게 되면 영속성 컨텍스트와 데이터베이스 간의 불일치가 발생할 수 있음
• 이를 방지하기 위해서 JPQL 쿼리를 실행하면 플러시를 자동으로 호출하여 우선 DB에 반영하도록 구성함

3) 플러시 모드 옵션

em.setFlushMode(FlushModeType.AUTO)	// 기본값
em.setFlushMode(FlushModeType.COMMIT)

• 위처럼 플러시 모드를 설정할 수 있는데 직접 설정할일은 크게 없으나 가끔 JPQL을 작성할 때 다른 엔터티에서 값을 가져올 때 굳이 플러시를 할 필요가 없기 때문에 옵션을 COMMIT으로 변경을 하여 플러시를 호출하지 않도록 할 수 있음
• 그러나.......... 큰 도움 안되기 때문에 그냥 AUTO로 쓰자!
• AUTO는 커밋이나 쿼리를 실행할 때 플러시를 함 - 기본값
• COMMIT은 커밋할 때만 플러시함(JPQL은 플러시 하지 않음)

4) 정리

• 플러시는 영속성 컨텍스트를 비우는 것이 아니라 영속성 컨텍스트의 변경내용을 데이터베이스에 동기화 하는 것!
• 트랜잭션이라는 작업 단위 때문에 커밋 직전에만 동기화를 하면 되어 플러시도, 쿼리를 모아서 날리는 등의 매커니즘이 전부 가능함

---

3. 준영속 상태

• JPA 웹 애플리케이션 만들기 강의에서 자세히 다뤘으므로 해당 내용을 확인, https://nagul2.tistory.com/328
• 영속 상태의 엔터티가 영속성 컨텍스트에서 분리된 상태가되어 영속성 컨텍스트가 제공하는 기능을 사용하지 못함
• 즉, JPA가 관리하지 않고 있는 상태를 말함
• 직접 준영속 상태를 만드는 경우는 거의 없지만 실제 애플리케이션 개발시 준영속 상태가 되어버려서 발생되는 문제가 있어서 알고 있어야 함

(1) 준영속 상태로 만드는 방법

• em.detach(entity) : 특정 엔터티만 준영속 상태로 전환
• em.clear() : 영속성 컨텍스트를 완전히 초기화, 테스트 케이스를 작성할 때 눈으로 직접 보기위해서 사용하는 경우가 있음
• em.close() : 영속성 컨텍스트를 종료