JPA #3 기본 사용법, 영속성 컨텍스트

📌 SQL 방언 (Dialect)

각 회사마다 다른 SQL 문법은 어떻게 처리할까? (Limit, ROWNUM)

org.hibernate.dialect 를 사용하면 된다. JPA와 DB의 의존성을 최소화 할수 있다.

Dialect은 한글로 방언, 사투리라는 뜻.

 

참고로 스프링부트를 사용하면 버전마다 기본으로 사용하는 Hibernate 버전이 다르므로, 버전을 설정할 때 주의하자.

Spring 사이트 - Projects - Spring Boot - Learn 탭으로 들어가서, Ref Docs에서 버전(Dependency)을 확인 할 수 있다.

 

Gradle, Maven 설정 방법

Gradle은 application.yml 설정파일에서 추가할 수 있다.

server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://...생략
    username: 유저명
    password: 비밀번호
    driver-class-name: com.mysql.cj.jdbc.Driver

  jpa:
    hibernate:
      dialect: org.hibernate.dialect.MySQL5InnoDBDialect // 이런 식으로 추가가능
      ddl-auto: none
    properties:
      hibernate:
        format_sql: true

  data:
    web:
      pageable:
        default-page-size: 10

 

Maven은 .../resources/META_INF/persistence.xml 을 만들어서 설정할 수 있다.

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.2"
  xmlns="http://xmlns.jcp.org/xml/ns/persistence"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_2.xsd">

  <!-- 데이터베이스 이름 -->
  <persistence-unit name="hello">
    <properties>
      <!-- 필수 속성 -->
      <property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
      <property name="javax.persistence.jdbc.user" value="sa"/>
      <property name="javax.persistence.jdbc.password" value=""/>
      <property name="javax.persistence.jdbc.url" value="jdbc:h2:tcp://localhost/~/test"/>
      <!--  H2 DB의 Dialect 설정 -->
      <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>

      <!-- 옵션 -->
      <property name="hibernate.show_sql" value="true"/>
      <property name="hibernate.format_sql" value="true"/>
      <property name="hibernate.use_sql_comments" value="true"/>
      <!--<property name="hibernate.hbm2ddl.auto" value="create" />-->
    </properties>
  </persistence-unit>
</persistence>

 

 

📌 JPA 구동 방식

EntityManager는 스레드간 공유해선 안된다. (사용하고 반납)

스프링 없이 JPA를 사용한다고 하면, 아래와 같은 코드가 나오게 된다.

public final class MemberService {

    public static void main(String[] args) {
        /* 어플리케이션이 시작할 때 Factory 생성한다. */
        EntityManagerFactory factory = Persistence.createEntityManagerFactory("hello");

        // 💭 1. 스레드에서 사용할 EntityManager 를 Factory 로 생성하고, 트랜잭션을 만든다.
        EntityManager entityManager = factory.createEntityManager();
        EntityTransaction tx = entityManager.getTransaction();

        // 💭 2. JPA를 이용한 모든 데이터 변경은 트랜잭션 안에서만 실행될 수 있다.
        try {
            Member member = new Member();
            member.setId(2L);
            member.setName("Kim");

            entityManager.persist(member);

            tx.commit();
        } catch (Exception e) {
            tx.rollback();
        } finally {
            // 💭 3. 사용이 끝난 EntityManager 반납한다.
            entityManager.close();
        }

        /* 어플리케이션이 종료할 때 필요없어진 Factory 반환한다. */
        factory.close();
    }
}

 

정말 자바 컬렉션을 다루는 것처럼 DB를 다룰 수 있다.

단순한 편의기능이 아니라, JPA를 사용하면 commit하는 시점에 변경된 부분을 감지하여 SQL 쿼리를 생성하기 때문이다.

try {
    Member findMember = entityManager.find(Member.class, 1L);
    findMember.setName("new_Name"); // 이름을 변경하였다.

    // entityManager.persist(findMember); ➡ 저장하지 않아도 업데이트 쿼리가 나가서 반영됨.
	    
    tx.commit();
} catch (Exception e) { ... }

 

코드를 보면 알겠지만, EntityManager는 데이터베이스 Connection처럼 사용된다.

즉 절대로 EntityManager를 공유해서는 안된다. 하나의 스레드에서 사용하고, 사용이 끝나면 반납해야한다.

그 이유는 트랜잭션 단위로 EntityManager를 사용하기 때문이다. 여러 스레드가 동시에 사용한다면, 영속성 컨텍스트와 DB 간의 데이터 동기화가 깨지게 된다. 커밋이 된 이후에는 영속성 컨텍스트는 반납했다가 새롭게 생성해야 한다.

 

 

📌 복잡한 조회는 어떻게 하죠?

단순히 컬렉션처럼 꺼내는게 아니라, 아래와 같이 복잡한 조건이 있다면 어떻게 사용할까?

• ID가 2이상이고, 이름이 KIM인 회원만 검색
• 전체 회원중 이름순으로 100명만 검색

이를 위해서 JPQL이라는 문법이 제공된다. 간단한 코드 예제를 적자면 아래와 같다.

try {
    List<Member> result = entityManager.createQuery("select m from Member", Member.class)
        .getResultList();

    tx.commit();
} catch (Exception e) {

다만 중요한 것은 JPQL을 이용하여 적은 select m from Member는 DB 테이블에 요청하는 쿼리가 아니다. 객체를 대상으로 하는 객체지향 SQL 문법이다. 즉 의미 그대로 [ Member 객체 ] 를 가져오는 문법이고 실제 SQL은 다르게 동작한다.

실제 결과도 테이블 데이터가 아니라, [ Member 객체 ] 가 반환된다.

JPA는 객체(Entity)를 중심으로 개발할 수 있게 제공해주는 도구이다.

모든 DB 데이터를 객체로 변환해서 검색하는건 상당히 비효율적이고, 사실상 불가능하다.

 

그래서 필요한 데이터만 DB에 요청하기 위해서 JPQL이라는 객체 전용 SQL문을 추가로 제공해주는 것이다.

다만 사용법은 SQL 문법과 거의 유사하다. SELECT, FROM, WHERE, GROUP BY, HAVING, JOIN 지원

 

 

📌 JPA의 비밀, EntityManager (영속성 컨텍스트)

JPA를 조금이라도 공부해봤다면 아래의 단어를 엄청 많이 들어봤을 것이다.

Persistence Context (영속성 컨텍스트)
- 엔티티를 영구 저장 하는 환경.
- 애플리케이션이 데이터베이스에서 꺼내온 객체를 보관하는 역할을 한다.

실제로 JPA에서 저장할 때 save() 라는 이름 대신, persist() 라는 이름을 사용한다. 굳이 헷갈리게 왜 이렇게 만들었을까?

 

@ EntityManager.persist( ~ )

사실 save 대신 persist 라는 이름을 사용한 이유는 간단하다.

실제 동작이 객체를 DB에 저장하는게 아니라, 영속성 컨텍스트에 저장(=persist)하기 때문이다.

 

이해하기 쉽게 코드를 통해 알아보자.

try {
    // 객체를 생성한 상태(비영속) 
    Member member = new Member();
    member.setId("member1");
    member.setUsername("회원1");
	
    // 객체를 저장한 상태 (영속)
    entityManager.persist(member)
    
    tx.commit();
} catch (Exception e) {
    tx.rollback();

비영속(new 또는 transient) , 영속(managed)

 

코드를 보면 em.persist()를 실행했을 때, DB에 저장되는 것처럼 보였다.

하지만 실제로 확인하면 em.persist()는 영속성 컨텍스트(EntityManager)에 있을 뿐, 아직 DB에 저장된게 아니다.

 

 

@ 영속성 컨텍스트 == EntityManager 인 건가요?

아니다. 정확히는 EntityManager가 영속성 컨텍스트를 사용할 수 있게 제공해주는 것이다.

아래와 같이 EntityManager에 객체가 존재하지만, 비영속 상태(=준영속) 으로 만들 수도 있다.

준영속은 마지막에 추가로 설명하겠다.

 

참고로 예제에서는 EntityManager당 고유한 영속성 컨텍스트를 가지고 있었지만, 스프링 프레임워크등을 사용할 떄에는 여러 개의 EntityManager가 하나의 영속성 컨텍스트를 공유해서 사용할 수도 있다. 

 

이는 영속성 컨텍스트를 공유한다기 보다는,

한 트랜잭션 안에서 여러 모듈이 호출되는 실행 구조, 예를 들어 Application ➡ Service ➡  Repository 와 같은 경우 EntityManager를 계속 공유하는게 아니라 새로운 EntityManager를 만들어 사용할 수 있는데, 이런 경우에만 하나의 영속성 컨텍스트를 공유한다는 말이다. 지금은 이해할 필요없으니 알아만두고 넘어가도록 하자.

 

 

@ 귀찮게 영속성 컨텍스트를 거치는 이유가 뭐죠?

DB에 바로 전송하지않고, 중간에 버퍼처럼 영속성 컨텍스트를 이용하는 이유는 여러가지가 있다.

• DB를 거치지 않고 1차 캐시에서 바로 사용가능
• 동일성 (identity) 보장
• 트랜잭션을 지원하는 쓰기 지연 (tx write-behind)
• 변경 감지를 통한 최적화 (Dirty Checking)
• 지연 로딩 지원 (Lazy Loading)

 

📌 영속성 컨텍스트의 특징

@ 1차 캐시 제공

EntityManager를 이용하면 DB를 거치지 않고, 중간에 캐시된 데이터를 바로 가져올 수 있다.

다만 한 트랜잭션 안에서만 사용할 수 있는 캐시(1차)라서 비즈니스 로직이 엄청 복잡한게 아니라면, 별 차이없다.

고객이 10명이면 10개의 1차 캐시가 만들어지는거니까. 그냥 구조상 얻는 소소한 이득이라고 생각하면 된다.

한 트랜잭션 내에서 재사용한다면, DB를 거치지 않고 영속성 컨텍스트에서 바로 꺼내온다.

즉 위와 같은 경우, DB에 Select 쿼리가 날라가지 않는다. 말 그대로 DB를 사용한 적이 없으니까.

 

 

@ 영속된 엔티티의 동일성 보장

JPA의 가장 큰 장점중 하나이다.

영속성 컨텍스트에서 객체를 관리하기 때문에, 객체를 여러번 조회하더라도 동일성을 보장한다.

이는 정말 큰 차이인게, 데이터베이스의 트랜잭션 격리 레벨을 3. REPEATABLE READ로 할 필요가 없어진다.

앱 (Java)단에서 [한 트랜잭션 내에 같은 데이터를 몇 번을 반복해서 읽어도] 동일성을 보장하기 때문이다.

 

 

@ 트랜잭션을 지원하는 쓰기 지연 제공

한 트랜잭션 내에서, em.persist()를 사용한다 하더라도 바로 DB에 저장되지 않게 쓰기 지연을 제공 해준다.

이는 EntityManager (영속성 컨텍스트)안에 캐시와 함께 쓰기지연 SQL 저장소를 가지고 있기 때문이다.

참고로 JPA는 JDBC Batch를 이용하여 쓰기 지연을 구현하였다. (hibernate.jdbc.batch_size 옵션 설정가능)

JPA를 사용하면 commit하는 시점에 변경된 부분을 감지하여 SQL 쿼리를 생성하기 때문이다.

위에도 언급했지만, 바로 저장하지 않고 [쓰기 지연 SQL 저장소]에 쿼리를 쌓아뒀다가 트랜잭션이 커밋하는 시점 (commit)에 변경된 부분만 감지하여, 최적화된 SQL문을 생성하게 된다.

persist()를 한다고 해서, DB에 쿼리가 날라가지 않는다. (*물론 설정으로 쓰기지연 취소 가능)

커밋하는 시점에 최적화된 SQL으로 DB를 사용한다.

이런 부분 때문에, 잘만 사용한다면 JDBC를 바로 작성하는 것 보다 JPA를 거치는게 성능이 더 좋을 수 있다는 말이 나온 것이다.

 

@ 변경 감지 (Dirty Checking)

이는 쓰기 지연과 비슷한 맥락이다. JPA는 Entity의 스냅샷을 찍어뒀다가, 커밋되는 시점에 변경된 부분을 찾아 최적화된 SQL을 생성해낸다.

try {
    // 업데이트는 2줄이면 끝.
    Member member = entityManager.find(Member.class, 1L);
    member.setName("new Name");
    
    // 저장할 필요가 없다. 변경되면 알아서 쿼리가 생성된다.
    // 이는 실제 컬렉션도 그렇다. 우리가 컬렉션을 변경하고, 따로 저장 메서드를 호출한적이 있던가?
    tx.commit();
} catch (Exception e) { ... }

* 참고로 flush를 사용해도 1차캐시는 변함없다. 그대로 제공됨. (쓰기 지연 SQL 저장소만 변경)

참고로 flush() 는 변경 내용을 반영하는 메서드이다. 만약 호출된다면 [쓰기 지연 저장소에 있는 쿼리]를 DB에 전송한다.

쉽게말해 플러시를 하는 시점에 DB 쿼리가 발생한다. 물론 커밋하기 전까지 실제 테이블에 반영은 되지 않겠지만.

 

트랜잭션이 커밋되거나 JPQL 쿼리가 실행되면 EntityManager.flush()가 자동으로 실행된다.

물론 EntityManager.flush()로 직접 호출하는 방법도 있지만, 우리가 사용할 일은 거의 없다.

JPQL의 경우에는, 여러 데이터를 조회하는 복잡한 쿼리를 임의로 캐싱해서 쓰기지연을 만들어버리면 문제가 생기기 쉽다. 기본적으로 JPQL을 실행하는 시점에 플러시, 즉 DB조회가 일어나도록 설정되어있다.

 

참고로 자동 플러시는 옵션으로 설정을 바꿀 수 있다. 물론 사용할 일은 없다.

쿼리 = JPQL.

헷갈릴까봐 언급하지만, 플러시는 영속성 컨텍스트를 삭제하거나 비우는게 아니다.

그냥 영속성 컨텍스트가 가지고있는 (쓰기 지연된) 변경 내용을 DB에 동기화 하는 것 뿐이다.

동기화를 늦게 해도 되는 이유는 트랜잭션 Commit 직전에만 동기화를 해주면 문제가 없기 때문이다.

 

 

@ 준영속 상태

EntityManager에는 존재하지만, 영속화 하지 않는 객체를 의미한다. 최근에는 `준영속` 대신 `영속상태 분리` 라고도 부른다. 그래서 메서드 명도 detached() 즉 영속성 컨텍스트에서 제공하는 변경감지, 쓰기 지연등을 사용하지 못한다.

clear()는 테스트 때 JPA의 동작을 보고싶을 때 종종 사용한다.

근데 JPA에서 객체를 관리하지 않는거면 그냥 비영속 상태, 즉 JPA를 안거치면 될 거 같은데 왜 굳이 준영속 상태라는걸 두고 EntityManager 안에서 객체를 사용하는 걸까?

 

그 이유는 '한번 영속상태가 되었다가 취소된 경우에도 객체의 식별자가 남아있기 때문' 이다.

이는 평소에는 거의 쓸 일이없고 복잡한 비즈니스 서비스를 만들때 종종 쓰이는데, 이는 JPA에 어느정도 익숙해 진 다음에 천천히 알아보도록 하자.