영속성 컨텍스트란 (JPA)

1. EntityManagerFactory와 EntityManager를 먼저 알아보자

자바 ORM 표준 JPA 프로그래밍(김영한) 자료

EntityManager란 사용자의 요청에 대하여 커넥션 풀에서 커넥션을 얻고 DB에 접근하는 역할을 한다.                              EntityManagerFactory란 말 그대로 사용자의 요청마다 EntityManger를 만들어내는 공장이다.

 

2. 영속성 컨텍스트가 뭘까 그래서

간단하게 엔티티의 Life Cycle을 관리하는 저장소이다.

EntityManager가 생성될 때 PersistenceContext가 같이 자동으로 생성된다.

 

3. Entity Life Cycle

• 비영속(new/transient): 영속성 컨텍스트와 관계없는 새로운 상태
• 영속(managed): 영속성 컨텍스트에 의해 관리되고 있는 상태
• 준영속(detached): 원래 영속성 상태였다가 현재는 분리되어 있는 상태
• 삭제(removed): 삭제된 상태

비영속 상태는 그저 new Book()처럼 객체를 생성만 해놓은 상태이고

영속 상태는 생성된 Book 인스턴스를 EntityManager를 통해 트랜잭션이 시작되고 persist가 되어 영속성 컨텍스트에서 관리되고 있는 상태이다.

 

4. 영속성 컨텍스트를 사용하면 좋은점 5가지만 알아보자

여기서는 간단하게만 적고 자세한건 나중에 다시 포스팅할 예정...

1. 1차 캐시                                                                                                                                          

영속성 컨텍스트 내부에 캐시를 가지며, Map 자료형으로 저장하는데 key는 Entity에서 @Id로 매핑한 식별자가 들어가고 value는 Entity의 인스턴스가 저장된다. 

em.persist(new Book(1L, "책1");

em.find(Book.class, 1L);

위와 같이 persist를 통해 영속성 컨텍스트에 의해 관리되는 Book에 대해서 조회를 하면 EntityManager는 먼저 영속성 컨텍스의 1차 캐시에 존재하는지 찾아보고 있으면 인스턴스를 반환하고 없으면 디비에서 찾아와서 1차 캐시에 저장하고  반환해주는 캐시 기능을 제공해준다.

하지만 이게 사실상 많은 상황에 도움이 안될수도 있다.

왜냐하면 영속성 컨텍스트는 EntityManager가 생성될 때 같이 생성되며 트랜잭션이 종료되면 같이 삭제가 되버리기 때문에 같은 트랜잭션 내에서만 이점이 있기 때문이다.

전체 어플리케이션에서 캐시기능을 사용하려면 2차 캐시를 사용해야 한다.

 

2. 동일성 보장   

영속성 컨텍스트에서 똑같은 것을 find했을 때 두 인스턴스를 == 비교하면 true이다.

헷갈릴 수 있는게 동등성은 실제 인스턴스는 다를 수 있지만 인스턴스가 가지고 있는 값이 같다는 의미이다. 동등성 비교를 위해서는 equals() 메서드를 구현해야 한다.

1차 캐시를 통해 REPEATABLE READ의 트랜잭션 isolation level을 DB가 아닌 어플리케이션 차원에서 제공한다.

 

3. 트랜잭션을 지원하는 쓰기 지연

persist 했을 때 바로 insert 쿼리가 날라가는게 아니라 transactional write-behind(쓰기 지연) sql 저장소에 insert sql문이 저장된다. transaction.commit()이 실행돼야 write behind sql 저장소에서 flush(영속성 컨텍스트의 변경 내용을 DB에 반영하는 것)가 발생하고  실제 DB에 insert 쿼리가 실행된다 그리고 commit(실제 트랜잭션을 종료하고 모든 작업을 정상 처리 확정하는 것)이 되어 종료된다.

쓰기 지연 SQL 저장소에 저장하면서 1차 캐시에도 인스턴스를 저장한다.

버퍼링으로 여러 개의 insert를 commit 전에 모아놨다가 commit 하면 batch size 설정한만큼 한방에 insert쿼리를 보낼 수 있다는 장점이 있다.

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

 

4. 변경 감지(Dirty Checking)                                                                                                                                                                           

Book book1 = em.find(Book.class, 1L);
book1.setName("책이름수정");

이때, 트랜잭션내에서 위와 같은 코드가 실행된다면 find를 실행하면 book1 인스턴스는 영속성 컨텍스트에 의해 관리가 되고 book1을 수정하면 commit 시점에 자동으로 변경사항이 반영된다. 따로 persist를 하지 않아도 된다.

조금 자세하게 말하자면

1차캐시에는 @Id로 설정해둔 식별자, 엔티티 인스턴스외에도 Snapshot이라는 필드가 더 있다. 스냅샷은 최초에 엔티티 인스턴스가 영속성 상태가 될 때의 상태를 저장해둔것이다.

(1)transaction.flush()가 실행되면 영속성 컨텍스트에서 (2)현재 엔티티 인스턴스와 스냅샷간의 차이가 있는지를 확인하고 차이가 있다면 (3)Update Sql문을 생성해서 쓰기 지연 Sql 저장소에 생성하고 실제 DB로 (4)flush되고 (commit 후 종료된다. 

5. 지연 로딩

지연 로딩이란 만약에 조인 컬럼을 가지고 있는 객체에서 조인된 객체에 대해서는 처음 디비에 조회 쿼리를 날렸을 때는 데이터를 가져오지 않고 나중에 조인된 객체에 대해서 get요청을 진행하면 그때 데이터를 가져오는 방식이다. lazy loading 의미대로 게으른 로딩으로 기억하면 된다!