JPA / 영속성 컨텍스트 / 변경 감지

"T아카데미 / JPA 프로그래밍 기본기 다지기 - 김영한 " 강좌를 듣고 정리한 글입니다.

 

변경 감지

아래 코드에서 SQL 버퍼, 쓰기 지연으로 memberA의 team 조회가 sql 쿼리보다 빠르고,

 

INSERT table 쿼리가 한개 뿐이며, sql쿼리보다 탐색이 빠름에도 불구하고 1차 캐시로 memberA의 팀 조회가 가능하다는 것을 알 수 있다.

Team teamA = new Team();
teamA.setName("TeamA");
em.persist(teamA);

Team teamB = new Team();
teamB.setName("TeamB");
em.persist(teamB);

Member member_A = new Member();
member_A.setName("memberA");
member_A.setTeam(teamA);

em.persist(member_A);

Member findMember = em.find(Member.class, member_A.getId());
Team findTeam= findMember.getTeam();

System.out.println(findTeam.getName());  // teamA

  

 jpa를 공부하면서 가장 신기했던건 아래 코드이다.

Team teamA = new Team();
teamA.setName("TeamA");
em.persist(teamA);

Team teamB = new Team();
teamB.setName("TeamB");
em.persist(teamB);

Member member_A = new Member();
member_A.setName("memberA");
member_A.setTeam(teamA);

em.persist(member_A);

member_A.setTeam(teamB);

Member findMember = em.find(Member.class, member_A.getId());
Team findTeam= findMember.getTeam();

System.out.println(findTeam.getName());

  이 코드의 결과값은 teamB이다.

 

memberA.setTeam(teamB) 이후에 em.persist()가 일어나지도 않았는데, 객체인 memberA의 필드값이 변경되는 것이 DB에 반영된다는 게 너무 신기했다.

 

이것이 변경 감지이고 이는 1차 캐시에 SQL에 올라가는 최초 상태의 객체 값이 저장되기 때문이다.

 

 

 

 

SQL이 flush 되기 전, SQL 버퍼에 저장될 당시의 객체 값 (스냅샷 값)과 엔티티의 현재 값을 비교하여 수정이 있을 경우 SQL을 일괄 변경하여 DB에 업데이트 하는 것이다. 이때 해당 객체만 변경하는 것이 아니라, 모든 객체의 SQL을 전부 변경한다.

 

비효율적인 부분도 있지만, 어플리케이션 로딩 시점에 수정 쿼리를 미리 생성해두고 재사용하는 방식으로 더 빠르게 처리한다고 한다.