Spring 입문 2주차 : JPA - 2

JPA의 트랜잭션

트랜잭션이란?

• 트랜잭션은 DB 데이터들의 무결성과 정합성을 유지하기 위한 하나의 논리적 개념
• 가장 큰 특징은 여러 개의 SQL이 하나의 트랜잭션에 포함될 수 있음
• 이때, 모든 SQL이 성공적으로 수행이 되면 DB에 영구적으로 변경을 반영하지만 SQL 중 단 하나라도 실패한다면 모든 변경을 되돌림

• 영속성 컨텍스트에 Entity 객체들을 저장했다고 해서 DB에 바로 반영되지 않음

• DB에서 하나의 트랜잭션에 여러 개의 SQL을 포함하고 있다가 마지막에 영구적으로 변경을 반영하는 것 처럼 JPA에서도 영속성 컨텍스트로 관리하고 있는 변경이 발생한 객체들의 정보를 쓰기 지연 저장소에 전부 가지고 있다가 마지막에 SQL을 한번에 DB에 요청에 변경을 반영함

• JPA에서 이러한 트랜잭션의 개념을 적용하기 위해서는 EntityManager에서 EntityTransaction을 가져와 트랜잭션 적용 가능

  • EntityTransaction et = em.getTransaction();

• et.begin(); : 트랜잭션 시작

• et.commit(); : 트랜잭션의 작업들을 영구적으로 DB에 반영

• et.rollback(); : 오류가 발생했을 때 트랜잭션의 작업을 모두 취소하고, 이전 상태로 되돌림

영속성 컨텍스트의 기능

📌 영속성 컨텍스트는 Entity 객체를 효율적으로 쉽게 관리하기 위해 만들어진 공간

1차 캐시

• 영속성 컨텍스트는 내부적으로 캐시 저장소를 가지고 있음
  • Entity 객체들이 1차 캐시 즉, 캐시 저장소에 저장됨
  • 캐시 저장소는 Map 자료구조 형태
    • key에는 @Id로 매핑한 기본 키 즉, 식별자 값을 저장
    • value에는 해당 Entity 클래스의 객체를 저장
    • 영속성 컨텍스트는 캐시 저장소에 key에 저장한 식별자 값을 사용하여 Entity 객체를 구분하고 관리

Entity 저장

• em.persist(memo); -> memo Entity 객체를 캐시 저장소에 저장

Entity 조회

1. 캐시 저장소에 조회하는 Id가 존재하지 않는 경우
   1. 캐시 저장소 조회
      
   2. DB SELECT 조회 후 캐시 저장소에 저장
      
      • em.find(Memo.class, 1); 호출 시 캐시 저장소에 해당 값이 없다면?
        -> DB에 SELECT 조회 후 해당 값을 캐시 저장소에 저장하고 반환
2. 캐시 저장소에 조회하는 Id가 존재하는 경우
   

• em.find(Memo.class, 1); 호출 시 캐시 저장소에 식별자 값이 1이면서 Memo Entity 타입인 값이 있는지 조회 -> 있다면 반환

• 1차 캐시 사용 장점

  1. DB 조회 횟수를 줄임
  2. 1차 캐시를 사용해 DB row 1개 당 객체 1개가 사용되는 것을 보장(객체 동일성 보장)

Entity 삭제

1. 삭제할 Entity를 조회한 후 캐시 저장소에 없다면 DB에 조회해서 저
   
2. em.remove(entity);
   
   • em.remove(memo); 호출 시 삭제할 Entity를 DELETED 상태로 만든 후 트랜잭션 commit 후 DELETE SQL이 DB에 요청됨

쓰기 지연 저장소(ActionQueue)

• JPA가 트랜잭션처럼 SQL을 모아서 한 번에 DB에 반영함
  • JPA는 이를 구현하기 위해 쓰기 지연 저장소를 만들어 SQL을 모아두고 있다가 트랜잭션 commit 후 한 번에 DB에 반영함
• flush()
  • 트랜잭션 commit 후 쓰기 지연 저장소의 SQL들을 한 번에 요청됨
  • 사실 commit 후 추가적인 동작이 있는데 이것이 em.flush(); 메서드 호출
  • flush 메서드는 영속성 컨텍스트의 변경 내용들을 DB에 반영하는 역할을 수행
    • 즉, 쓰기 지연 저장소의 SQL들을 DB에 요청하는 역할을 수행

• em.flush(); 호출되자 바로 DB에 쓰기 지연 저장소의 SQL이 요청
• 이미 쓰기 지연 저장소의 SQL이 요청되었기 때문에 더 이상 요청할 SQL이 없어 트랜잭션이 commit 된 후에 SQL 기록이 없음

• 추가) 트랜잭션을 설정하지 않고 flush 메서드를 호출하면 no transaction is in progress 메세지와 함께 TransactionRequiredException 오류가 발생
  • insert, update, delete 즉, 데이터 변경 SQL을 DB에 요청 및 반영하기 위해서는 트랜잭션이 필요

    변경 감지(Dirty Checking)

• 영속성 컨텍스트에 저장된 Entity가 변경될 때마다 Update SQL이 쓰기 지연 저장소에 저장된다면??????
  • 하나의 Update SQL로 처리할 수 있는 상황을 여러 번 Update SQL을 요청하게 되기 때문에 비효율적
• 그렇다면 JPA는 어떻게 Update를 처리?
  • em.update(entity); 같은 메서드는 없음 😭

• JPA는 영속성 컨텍스트에 Entity를 저장할 때 최초 상태(LoadedState)를 저장
  • 트랜잭션이 commit되고 em.flush();가 호출되면 Entity의 현재 상태와 저장한 최초 상태를 비교
  • 변경 내용이 있다면 Update SQL을 생성하여 쓰기 지연 저장소에 저장하고 모든 쓰기 지연 저장소의 SQL을 DB에 요청
  • 마지막으로 DB의 트랜잭션이 commit 되면서 반영됨
• 따라서 변경하고 싶은 데이터가 있다면 먼저 데이터를 조회하고 해당 Entity 객체의 데이터를 변경하면 자동으로 Update SQL이 생성되고 DB에 반영됨
  • 이러한 과정을 변경 감지, Dirty Checking이라고 함