[TIL] 221206 - JPA : 영속성 컨텍스트

JPA (2) - 영속성 컨텍스트

• EntityManagerFactory, EntityManager 학습
• 영속성 컨텍스트
• 엔티티의 생명주기
• 영속성 컨텍스트 특징과 실습

 

EntityManagerFactory, EntityManager

 

Entity

RDB의 table과 매핑되는 객체

 

EntityManagerFactory

Entity를 관리하는 Entity Manager를 생산하는 공장.

: 비용이 비싸 하나만 만들어지고 Entity Manager를 생산하는 factory성 bean

: Thread safe하다. 하나에 여러 스레드가 접근해도 안전하다.

 

EntityManager

Entity를 저장, 수정, 삭제, 조회 (CURD) 등 entity와 관련된 모든 일을 처리한다.

: Thread Safe하지 않다. EntityManagerFactory에 의해 새로운 manager를 생성해주며 단일 스레드가 접근하도록 사용한다.

 

https://ttl-blog.tistory.com/108https://ttl-blog.tistory.com/108

엔티티 메니저는 트랜잭션에 commit이 일어날때 그때서야 connetion을 가져와 사용한다.

 

 

영속성 컨텍스트

 

영속성 컨텍스트

• JPA를 이용하는데 가장 중요한 요소
• Entity를 영구 저장하는 환경
• Entity manager는 엔티티를 영속성 컨텍스트에 보관하고 관리한다.

 

영속성 컨텍스트의 특징

• 영속성 컨텍스트 와 식별자 값

: 영속성 컨텍스트 안에서 관리되는 엔티티는 식별자 값을 반드시 가져야한다.

: key-value로 엔티티를 관리하기 때문에 (1차 캐시에서)

@Entity class에 @id 필드를 지정하지 않으면 오류가 나는 이유.

 

 

• 영속성 컨텍스트와 데이터 베이스 저장

: JPA는 트랜잭션을 커밋하는 순간 영속성 컨텍스트에 새로 저장된 엔티티를 DB에 반영한다.(FLUSH)

: 플러시는 영속성 컨텍스트의 변경 내용을 DB에 동기화하는 작업.

 

 

• 영속성 컨텍스트가 엔티티를 관리함으로 얻는 이점.
  1. 1차 캐시
  2. 동일성 보장
  3. 트랜잭션을 지원하는 쓰기 지연
  4. 변경 감지(dirty checking)
  5. 지연 로딩

 

엔티티 생명주기

비영속 (new / transient) : 영속성 컨텍스트와 전혀 관계가 없는 상태

// 객체가 영속성컨텍스트, 데이트베이스와 무관한 상태이다.
Customer customer = new Customer(); 
customer.setId(1L);
customer.setFirstName("honggu");
customer.setLastName("kang");

 

영속 (managed) : 영속성 컨텍스트에 저장된 상태

Customer customer = new Customer();
customer.setId(1L);
customer.setFirstName("honggu");
customer.setLastName("kang");

// customer객체가 영속성 컨텍스트에서 관리된다.
// em.find()나 JPQL를 사용해서 조회한 엔티티도 영속 상태.
em.persist(customer);

 

준영속 (detached) : 영속성 컨텍스트에 저장되었다가 분리된 상태

// 영속상태의 customer객체(엔티티)를 영속성컨텍스트에서 분리한다.
em.detach(customer);
// 영속상태의 모든 객체를 영속성컨텍스트에서 분리한다.
em.clear()
// 영속성컨텍스트를 종료한다.
em.close()

em.merge(customer);

 

삭제 (removed) : 삭제된 상태

// customer 엔티티를 영속성컨텍스트에서 분리하고, DB에서도 삭제한다.
em.remove(customer)

 

영속성 컨텍스트를 플러시하는 방법 3가지

1. em.flush() 직접 호출.
2. 트랜잭션 커밋시 플러시가 자동 호출.
3. JPQL (Java Persistence Query Langauge) 쿼리 실행시 플러시가 자동 호출.

 

 

 

영속성 컨텍스트 이해하기

 

✅ 저장

EntityManager em = emf.createEntityManager(); // 1)엔티티 매니저 생성

EntityTransaction transaction = em.getTransaction(); // 2)트랜잭션 획득
transaction.begin(); // 3)트랙잰셕 begin

Customer customer = new Customer(); // 4-1)비영속
customer.setId(1L);
customer.setFirstName("honggu");
customer.setLastName("kang");

em.persist(customer); // 4-2)영속화

transaction.commit(); // 5)트랜잭션 commit
// 트랜잭션이 커밋이 되는 순간 쿼리가 수행된다. flush DB와 동기화가 된다.

쓰기 지연 저장소에 쿼리 저장 → 1차 캐시에 저장 → commit → DB와 동기화

 

 

✅ 조회

→ 1차 캐시를 이용한 조회

@Test
void 조회_1차캐시_이용() {
	EntityManager em = emf.createEntityManager();
  EntityTransaction transaction = em.getTransaction();
  transaction.begin();

  Customer customer = new Customer();
  customer.setId(1L);
  customer.setFirstName("honggu");
  customer.setLastName("kang");

	em.persist(customer);
  transaction.commit();

  Customer entity = em.find(Customer.class, 1L); // 1차 캐시에서 조회한다.
  log.info("{} {}", entity.getFirstName(), entity.getLastName());
}

: 1차 캐시에 있을 경우, DB에 질의하지 않고 1차 캐시에서 정보를 가져온다.

 

→ DB를 이용한 조회

@Test
void 조회() {
	EntityManager em = emf.createEntityManager();
	EntityTransaction transaction = em.getTransaction();
  transaction.begin();

	Customer customer = new Customer();
  customer.setId(2L);
  customer.setFirstName("guppy");
  customer.setLastName("hong");

  em.persist(customer);
  transaction.commit();

  em.clear(); //영속성 컨텍스트를 초기화 한다.

  Customer entity = em.find(Customer.class, 2L); // DB 에서 조회한다. SELECT ...
  log.info("{} {}", entity.getFirstName(), entity.getLastName());
  em.find(Customer.class, 2L); // SELECT Query 수행되지 않는다. 1차캐시 사용
}

: 1차 캐시에 없을 경우, DB에 질의하여 1차 캐시에 저장후 결과를 반환

 

 

✅ 수정

@Test
void 수정() {
    EntityManager em = emf.createEntityManager();
    EntityTransaction transaction = em.getTransaction();
    transaction.begin();

    Customer customer = new Customer();
    customer.setId(1L);
    customer.setFirstName("honggu");
    customer.setLastName("kang");

    em.persist(customer);
    transaction.commit();
    // 엔티티를 영속화한후, 커밋을해서 flush()를 통해 DB에 저장.

    transaction.begin();

    Customer entity = em.find(Customer.class, 1L);
    entity.setFirstName("guppy");
    entity.setLastName("hong");

    // em.update(entity) ??!! 
    transacton.commit(); // flush -> UPDATE ... 
}

dirty checking(변경 감지) 수행

→ 스냅샷과 비교하여 변경사항이 있는지 확인한다. 변경 사항이 있으면 쓰지 기연 저장소에서 update 쿼리를 날린다.

: 영속성 컨텍스트에 엔티티를 보관할때, 최초 상태를 복사해서 저장해두는데 이것을 스냅샷이라 한다.

: 플러시 시점에 스냅샷과 엔티티를 비교하여 변경 사항을 찾아, 변경을 수행한다. 즉, update를 직접 해줄 필요가 없다! (영속 상태 엔티티만 적용됨)

: 모든 필드가 변경되는 것이 싫다면 엔티티를 정의할 때 @DynamicUpdate 어노테이션을 추가하면 실제로 update 되는 필드에 대해서만 update를 수행합니다.

 

 

✅ 삭제

@Test
void 삭제() {
    EntityManager em = emf.createEntityManager();
    EntityTransaction transaction = em.getTransaction();
    transaction.begin();

    Customer customer = new Customer();
    customer.setId(1L);
    customer.setFirstName("honggu");
    customer.setLastName("kang");

    em.persist(customer);
    transaction.commit();

    transaction.begin();

    Customer entity = em.find(Customer.class, 1L);
    em.remove(entity);
    
    transaction.commit(); // flush -> DELETE ..
}

 

영속성 컨택스트를 이용하면 JpaRepository 인터페이스는 필요없나?

 

엔티티 매핑 - 단일 엔티티 매핑

JPA 엔티티 객체를 생성할때, 기본 생성자를 사용한다.

final 필드는 못만드나?

 

 

데이터베이스 스키마 자동생성

spring:
  h2:
    console:
      enabled: true
  jpa:
    generate-ddl: true
    database: H2
    show-sql: true
    open-in-view: false
    properties:
      hibernate:
        dialect: org.hibernate.dialect.H2Dialect
        query.in_clause_parameter_padding: true
        hbm2ddl:
          auto: create-drop  # 테스트 코드 작성할때 많이 사용

운영 환경에서는 validation, none 을 많이 사용하고

create, create-drop, update 설정은 실제 테이블에 영향을 주기 때문에 개발환경이나 테스트 환경에서 많이 사용한다.

 

 

DDL 옵션

굳이 사용하지 않아도 가독성을 위해 명시해 주는것을 권장한다.

@Entity
@Table(name = "member")
@Getter
@Setter
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE)
    private Long id;

    @Column(name = "name", nullable = false, length = 30)
    private String name;

    @Column(nullable = false, length = 30, unique = true)
    private String nickName; // nick_name

    private int age; // age

    @Column(name = "addres", nullable = false) // 크기를 정의하지않으면 디폴트 값 = 255
    private String address;
    
    @Column(name = "description", nullable = true)
    private String description;
}

—-

# drop 옵션
drop table if exists member CASCADE 
drop sequence if exists hibernate_sequence
# create 옵션
create sequence hibernate_sequence start with 1 increment by 1
create table member (id bigint not null, address varchar(255) not null, age integer not null, description varchar(255), name varchar(30) not null, nickName varchar(30) not null, primary key (id))
alter table member add constraint UK_1m3ighjll05v7njjxeopp823j unique (nickName)

 

 

기본키 매핑전략 @Id

• 직접할당

@Id
@Column(name = "id")
private Long id;

 

• SEQUENCE

: 데이터베이스 시퀀스에서 식별자 값을 획득한 후 영속화

: ORACLE, H2

@Id
@GeneratedValue(strategy = GenerationType.SEQUENCE)
private Long id;

 

• TABLE

: 데이터베이스 시퀀스 생성용 테이블에서 식별자 값을 획득한 후 영속화

 

• IDENTITY

: 데이터베이스 엔티티를 저장해서 식별자 값을 획득한 후 영속화

: em.persist() 시점에 INSERT 쿼리가 수행되고 그 결과로 key 값을 가져온다.

: MySQL (AUTO_INCREMENT)

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

 

• AUTO

: 데이터 베이스 방언(dialect)에 따라서 자동으로 전략을 선택. 엔진에 맞는 최적화된 전략이 사용된다.

 

 

기타 컬럼매핑

@Entity
@Table(name = "orders")
public class Order {

    @Id
    @Column(name = "id")
    private String uuid;

    @Column(name = "order_datetime", columnDefinition = "TIMESTAMP")
    private LocalDateTime orderDatetime;

    @Enumerated(EnumType.STRING)
    private OrderStatus orderStatus;

    @Lob // long text 타입
    private String memo;
}

---

데이터 중심 설계의 문제점

@Test
    void 잘못된_설계() {
        Member member = new Member();
        member.setName("youngji");
        member.setAddress("울집");
        member.setAge(33);
        member.setNickName("young");
        member.setDescription("백앤드 개발자에요.");

        EntityManager entityManager = emf.createEntityManager();
        EntityTransaction transaction = entityManager.getTransaction();
        transaction.begin();

        entityManager.persist(member);
        Member memberEntity = entityManager.find(Member.class, 1L);

        Order order = new Order();
        order.setUuid(UUID.randomUUID().toString());
        order.setOrderDatetime(LocalDateTime.now());
        order.setOrderStatus(OPENED);
        order.setMemo("부재시 전화주세요.");
        order.setMemberId(memberEntity.getId()); // 외래키를 직접 지정

        entityManager.persist(order);
        transaction.commit();

        Order orderEntity = entityManager.find(Order.class, order.getUuid());
        // FK 를 이용해 회원 다시 조회
        Member orderMemberEntity = entityManager.find(Member.class, orderEntity.getMemberId());
        // orderEntity.getMember() 
		// 객체중심 설계라면 객체그래프 탐색을 해야하지 않을까?
        log.info("nick : {}", orderMemberEntity.getNickName());
    }

order에서 회원 객체를 가져오는게 아니라 FK로 다시 회원테이블을 조회해야한다.

→ 실제 엔티티 객체 사이에는 서로를 참조하지 않는다.

 

 

 

 

출처 - backend dev course 강홍구님