728x90
반응형
- EntityManagerFactory에서 Request가 올 때마다 EntityManager를 생성 -> 내부적으로 데이터베이스 Connection 사용한다.
✍영속성
- JPA를 이해하는데 가장 중요한 용어, 영속성 = "엔티티를 영구 저장하는 환경" 이라는 뜻
(application과 DB사이의 중간 계층).
- 비영속 : 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태.
- 영속 : 영속성 컨텍스트에 관리되는 상태.
- 준영속 : 영속성 컨텍스트에 저장되었다가 분리된 상태.
- EntityManager을 통해 영속성 컨텍스트에 접근. 영속성 컨텍스트와 트랜잭션의 생명 주기를 맞춰주는 것이 중요.
영속성 컨텍스트의 이점
- 1차 캐시 : 영속 컨텍스트 안에 1차 캐시가 존재. JPA에서 Entity객체를 영속성 컨텍스트에 저장하거나, DB에서 특정 데이터를 조회할 때, 1차 캐시 안에 [@Id - Entity 객체] 가 저장됨. 따라서, 조회 할 때 1차 캐시에서부터 해당 Entity가 존재하는지 조회한다. 하지만, 트랙잭션이 끝나면 영속성 컨테스트를 지워버린다. 따라서, 성능의 이점이 아주 크진 않다.
- 동일성 보장 : DB에서 동일한 데이터(같은 PK)를 꺼내서 객체 비교를 할 때 논리적으로 동일하다는 것을 보장해줌.
1차캐시에 Entity가 있기 때문. - 트랜잭션을 지원하는 쓰기 지연 : em.persist(Entity) 에서 INSERT SQL을 보내지 않고 쌓아놓다가. 트랜잭션을 커밋하는 순간 데이터베이스에 INSERT SQL을 보낸다. Entity 객체를 영속할때 1차 캐시에 해당 ID와 객체 참조를 저장하고 '쓰기 지연 SQL 저장소'에 INSERT SQL을 저장한다. => SQL 쓰기 지연 => 버퍼링을 모아서 Write하기 때문에 약간의 성능 향상을 기대할 수 있다.
- 변경 감지 : 더티 체킹에 관한 내용. JPA 목적인 자바 컬렉션처럼 DB를 이용할 수 있는 특성. 데이터를 최초 조회한 시점에 해당 데이터의 스냅샷을 떠서 1차 캐시에 저장한다. 이후, Transaction.commit()시 스냅샷과 엔티티를 비교하여 둘이 다르다면 쓰기지연 SQL 저장소에 UPDATE SQL을 생성한다.
- 지연 로딩
flush : (작업 - 더티체킹, 수정된 엔티티 쓰기 지연 SQL 저장소에 등록, 쿼리 보냄) / 영속성 컨텍스트를 비우지 않음. 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화 시키는 작업. 트랜잭션이라는 작업 단위가 중요!
준영속 상태
- persist()와 find() 등의 작업을 통해 영속상태가 됨. -> detach()등의 메소드로 준영속 상태로 전환.
- 영속 상태인 엔티티가 영속성 컨텍스트에서 분리된 상태 => 영속성 컨텍스트가 제공하는 기능을 사용하지 못함.
준영속 상태로 전환하는법
- detach(Entity) : 인자로 받은 엔티티를 영속성 컨텍스트에서 제외시킴.
- clear() : 영속성 컨텍스트를 완전히 초기화.
- close() : 영속성 컨텍스트를 닫아버림.
JPA의 더티 체킹에 대한 추가적인 설명 (이동욱 님 글 참조)
https://jojoldu.tistory.com/415
본 게시글은 Inflearn 강의를 토대로 제작되었습니다.
https://www.inflearn.com/course/ORM-JPA-Basic/dashboard
728x90
반응형