JPA(Java Persistence API) 개요

• 자바 진영의 ORM(Object Relational Mapping) 기술 표준으로 ORM 기술을 사용하기 위한 표준
  인터페이스의 모음이다.
• ORM은 자바 객체와 DB테이블을 매핑하고 자바 객체간의 관계를 토대로 SQL을 생성 및 실행 할 수
  있으며 대중적인 언어에는 대부분 ORM 기술이 존재한다.
• JPA 2.1 기준 표준 명세를 구현한 구현체들(Hibernate, EclipseLink, DataNucleus) 중에 대부분 Hibernate를 사용하므로 JPA를 활용하기 위해서는 Hibernate를 사용하게 된다.

JPA 역사

• 1997 년 IBM에서 개발되었고 1999 년에 Sun Microsystems로 인수된 EJB(Enterprise JavaBeans)라는 자바 표준이 있었는데 지저분한 코드와 느리고 제대로 동작하지도 않는 결함이 많은 기술이었다.
• Gavin King이 EJB 컨테이너에 의존하지 않는 ORM 프레임워크인 Hibernate를 만들게 되고 오픈소
  스화가 되어 EJB는 사라지게 되었다.
• 이후 Java와 GavinKing이 같이 Java표준을 만들게 되었고 2006 년에 JPA 1.0이라는 JPA의 초기버전이 나온 이후 현재까지 JPA는 2.1버전까지 사용되고 있다.

  JPA 1.0은 2006 년 5 월 11 일, 자바커뮤니티 프로세스 JSR220에서 최종 배포되었다.
  JPA 2.0은 2009 년 12 월 10 일에 배포되었다.
  JPA 2.1은 2013 년 4 월 22 일에 배포 되었다.

출처 : 위키백과

JPA의 특징

• 영속성 컨텍스트가 엔티티를 생명주기를 통해 관리한다.
• native SQL을 통해 직접 SQL을 해당 DB에 맞게 작성할 수도 있다.
• DBMS별로 dialect를 제공한다.

JPA의 사용 이유

JPA의 장점

• 객체지향과 관계지향이라는 서로다른 패러다임 불일치를 해소해 주며 SQL 중심이 아닌 객체지향 패러다임 중심의 개발이 가능하다.
• 개발자가 직접 SQL을 따로 작성하지 않아도 SQL문을 작성해 주므로 생산성이 향상된다.
• SQL을 수정할 필요가 없으므로 설정 및 필드 변경시 SQL이 자동 수정되어 유지보수가 향상된다.
• DB의 종류에 따라 SQL문에 있어 다소 차이가 있지만 JPA는 개발자 대신 이를 판단하고 해당 DB에 맞는 SQL을 작성해 준다.
• 캐시를 활용한 성능 최적화로 인해 트랜잭션을 처리하는 시간이 굉장히 많이 단축된다.

JPA의 단점

• 너무 복잡한 SQL을 작성하기에는 적합하지 않다.
• JPA를 제대로 이해하지 못하고 작성시 성능저하가 발생할 수 있다.
• 객체지향 패러다임과 관계형 데이터베이스 패러다임에 대한 이해가 없는 상태로는 제대로 이해할 수 없다.
• 복잡한 동적 SQL같은 경우 순수 JPA만으로는 부족한 부분에 있어 추가 라이브러리를 활용해야 할 경우가 생길 수 있다.

마이바티스(MyBatis)와 JPA

• Mybatis는 SQL Mapper로 SQL Mapping을 사용하는 영속성(DB저장) 프레임워크이다. 개발자가 직접 SQL코드를 작성하고 객체에 대해 매핑을 위한 설정을 모두 직접 처리해야 한다. 또한, 수정이 이루어질 시 SQL뿐 아니라 매핑 될 객체까지 같이 수정해야 하는 번거로움이 있다.
• JPA와 마이바티스는 분류상 서로 다르다. JPA는 ORM 기술이고, Mybatis는 SQL Mapper의 한 종류
  이다.
• 어플리케이션이 고도화 되면 JPA를 구현하여 손이 많이 가는 것 보다 Mybatis가 답이 될 수도 있다.
  (JPA가 무조건 좋은 것이 아니다. 다만 JPA는 추가 라이브러리를 활용하면 복잡한 SQL이나 동적
  SQL에 있어서 도움을 받을 수 있다.)

JPA의 원리

JPA의 기본 동작방식

• Java 애플리케이션과 JDBC사이에서 동작하며 내부적으로 JDBC API를 활용한다.

• JPA는 엔티티를 저장하는 환경인 영속성 컨텍스트(Persistence Context)를 통해 엔티티를 보관하
  고 관리한다.

엔티티의 영속성 컨텍스트(Persistence Context)에서의 생명 주기

• 엔티티 메니저가 엔티티를 저장하는 공간으로 엔티티를 보관하고 관리한다.
• 엔티티 매니저가 생성될 때 하나의 영속성 컨텍스트가 만들어 진다.
• 엔티티의 생명주기

상태	설명
비영속 (new/transient)	엔티티가 영속성 컨텍스트와 전혀 관계가 없는 상태
영속 (managed)	엔티티가 영속성 컨텍스트에 저장된 상태 준영속(detached): 영속성 컨텍스트에 저장되었다가 분리된 상태
삭제 (removed)	엔티티가 삭제된 상태
병합 (merge)	엔티티가 준영속 상태인 엔티티가 다시 영속상태로 변경된 상태

영속성 컨텍스트가 엔티티를 관리하는 원리

• 1차 캐시

  • 영속성 컨텍스트 내부에 Map으로 관리되는 캐시(key는 @Id이며 매핑한 식별자이고 value은 엔티티 인스턴스이다.)이며 이 곳에 있는 엔티티는 캐시에서 바로 불러와서 조회 성능이 올라간다.

• 동일성 보장

  • 반복해서 호출 시 1 차 캐시에서 같은 엔티티 인스턴스를 가져올 수 있다.

• 트랜잭션을 지원하는 쓰기 지연(transactional write-behind)

  • (엔티티 등록(INSERT)을 예로 들면) 엔티티 매니저는 트랜잭션을 커밋하기 직전까지 데이터베이스에 저장(flush) 대신 쓰기 지연 SQL 저장소에 INSERT SQL을 차곡차곡 쌓게 되며 커밋 시에 쿼리를 데이터베이스로 보내는데 이를 트랜잭션을 지원하는 쓰기 지연이라고 한다.
  • 플러시(flush): flush()는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다.
    • 플러시 절차
      • 1. 영속성 컨텍스트에 보관할 때 최초 엔티티 상태를 복사해서 스냅샷으로 저장해 두고 모든 엔티티를 스냅샷과 비교해서 수정된 엔티티를 찾아서 수정 쿼리를 만들어 쓰기 지연 SQL 저장소에 보낸다.
      • 2. 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 저장한다.
      • 3. 플러시를 하는 경우: a. em.flush()를 직접 호출한다.
      • 4. 트랜잭션 커밋 시 플러시가 자동 호출한다.
      • 5. JPQL 쿼리 실행 시 플러시가 자동 호출한다.

• 변경 감지(dirty checking)

  • SQL에 의존적이지 않도록 엔티티의 데이터 변경을 감지하고 데이터베이스에 자동으로 반영하는 기능을 변경 감지라고 한다.
    • 영속성 컨텍스트에 보관할 때 최초 엔티티 상태를 복사해서 저장한 스냅샷과 이를 비교하여 감지한다.
    • 영속 상태의 엔티티에만 적용된다.(준영속이나 비영속은 해당되지 않는다.)

• 변경 감지는 절차(커밋 실행 시)

  • 1. 우선 엔티티 매니저 내부에서 먼저 플러시(flush)가 호출된다.
  • 2. 엔티티와 스냅샷을 비교해서 변경된 엔티티를 찾는다.
  • 3. 변경된 엔티티와 관련된 수정 쿼리를 생성해서 쓰기 지연 SQL 저장소에 보낸다.
  • 4. 쓰기 지연 저장소의 SQL을 데이터베이스로 보낸다.
  • 5. 데이터베이스에서 트랜잭션을 커밋한다.