영속성 컨텍스트를 사용하는 이유
-
그러면 영속성 컨텍스트를 왜 사용할까?
-
영속성 컨텍스트를 사용함으로써 얻을 수 있는 이점을 알아보자
1. 1차 캐시
-
영속성 컨텍스트 내부에는 위와 같이 1차 캐시라는 공간이 있다.
-
persist()를 한다고 해서 바로 DB에 insert문이 날아가는게 아닌, 해당 1차 캐시 공간에 저장된다.
-
이렇게 된다면, 특정 Entity에 대한 삽입과 조회가 동시에 일어나게 된다면 DB에 insert문와 select문을 실행해 DB에 접근할 필요 없이 단순히 이 1차 캐시에서 Entity를 가져오기만 하면 되는 것이다.
- 단, 1차 캐시는 한 Transaction의 생명주기가 같으므로 눈에 띄는 큰 속도 이점은 없다고 볼 수 있다.
2. 동일성 보장
- DB에서 조회한 Data를 기반으로 새로운 Entity를 생성하는 것이 아닌, 1차 캐시에서 삽입, 조회를 하므로, JCF같이 동일성 보장이 된다.
User findUser1 = em.find(User.class, "user1");
User findUser2 = em.find(User.class, "user2");
System.out.println(findUser1 == findUser2); // true- 같은 객체를 바라보고 있다.
3. 쓰기 지연
- Entity들을 1차 캐시에 저장할 때, 저장할 뿐만 아니라 쓰기 지연 SQL 저장소라는 곳에 해당 SQL문도 함께 저장한다.
-
미리 SQL문들을 저장하고 있다가, 트랜잭션 커밋을 실행할 때, 미리 저장해두었던 SQL문들을 한번에 실행한다.
-
즉, 버퍼링같은 기능. 한번에 모았다가 한번에 실행
4. 변경 감지
- jpa에서 update를 할 때, 따로 update()나 modify()가 없다.
Member member = entityManager.find(Member.class, 1l)
member.setName("updateName");-
find()로 member를 조회한 다음 data를 변경하기만 하면 이를 감지해, commit()할 때 update문이 알아서 생성되어 날아간다.
-
이는 아래와 같은 흐름덕분에 가능하다.
-
1차 캐시에는 스냅샷이라는 공간이 있다.
- snapshot : 1차(최초)로 객체가 들어왔을 시점을 저장
- Entity : 실제 저장된 Entity
-
flush()가 실행될 때, 먼저 Entity와 스냅샷을 비교한다.
-
위의 코드에서는 Name을 변경했기에, Entity의 Name과 스냅샷의 Name이 다른 것을 감지해 자동으로 Update문을 생성하는 것이다.
출처 및 참고
Be More!