SQL 중심적인 개발의 문제점
- 무한 반복, 지루한 코드
- 엔티티 신뢰 문제
- 모든 객체를 미리 로딩할 수 없다.
- 계층형 아키텍처의 진정한 의미의 계층 분할이 어렵다.
- 객체답게 모델링 할수록 매핑 작업만 늘어나게 됨.
- 객체를 자바 컬렉션에 저장 하듯이 db에 저장할 필요성 생김.
- 객체와 관계형 데이터베이스의 차이
- 상속
- 연관관계
- 데이터 타입
- 데이터 식별 방법
JPA
- Object-relational mapping
- 객체는 객체대로 설계
- 관계형 데이터베이스는 관계형 데이터베이스대로 설계
- ORM 프레임워크가 중간에서 매핑
- 대중적인 언어에는 대부분 ORM 기술이 존재
JPA의 성능 최적화 기능
- 1차 캐시와 동일성 보장
- 같은 트랜잭션 안에서는 같은 엔티티를 반환 - 약간의 조회 성능 향상
- DB Isolation Level이 Read Commit이여도 애플리케이션에서 Repeatable Read 보장
- 트랜잭션을 지원하는 쓰기 지연
- 트랜잭션을 커밋할 때까지 INSERT SQL을 모음
- JDBC BATCH SQL 기능을 사용해서 한번에 SQL 전송
- 지연 로딩
- 지연 로딩과 즉시 로딩
- 지연 로딩: 객체가 실제 사용될 때 로딩
- 즉시 로딩: JOIN SQL로 한번에 연관된 객체까지 미리 조회
영속성 관리 - 내부 동작 방식
영속성 컨텍스트
- JPA를 이해하는데 가장 중요한 용어
- "엔티티를 영구 저장하는 환경"이라는 뜻
- EntityManager.persist(entity);
- 영속성 컨텍스트는 논리적인 개념
- 눈에 보이지 않음
- 엔티티 매니저를 통해서 영속성 컨텍스트에 접근
엔티티의 생명주기
- 비영속 (new/transient)
영속성 컨텍스트와 전혀 관계가 없는 새로운 상태 - 영속 (managed)
영속성 컨텍스트에 관리되는 상태 - 준영속 (detached)
영속성 컨텍스트에 저장되었다가 분리된 상태 - 삭제
삭제된 상태
영속성 컨텍스트의 이점
- 1차 캐시
- 동시성 보장
- 트랜잭션을 지원하는 쓰기 지연
- 변경 감지
- 지연 로딩
플러시
- 영속성 컨텍스트의 변경내용을 데이터베이스에 반영
- 변경 감지
- 수정된 엔티티 쓰기 지연 SQL 저장소에 등록
- 쓰기 지연 SQL 저장소의 쿼리를 데이터베이스에 전송 (등록, 수정, 삭제)
- 1차 캐시가 지워지지는 않음
- JPQL 쿼리 실행 시, flush 호출 시, commit 시 실행
영속성 컨텍스트를 비우지 않음
영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화
트랜잭션이라는 작업 단위가 중요 -> 커밋 직전에만 동기화 하면 됨
준영속 상태
- 영속 -> 준영속
- 영속 상태의 엔티티가 영속성 컨텍스트에서 분리 (detached)
- 영속성 컨텍스트가 제공하는 기능을 사용 못함
- 준영속 상태로 만드는 방법
- em.detach(entity): 특정 엔티티만 준영속 상태로 전환
- em.clear(): 영속성 컨텍스트를 완전히 초기화
- em.close(): 영속성 컨텍스트를 종료
엔티티 매핑
객체와 엔티티 매핑
- @Entity가 붙은 클래스는 JPA가 관리, 엔티티라 한다.
- JPA를 사용해서 테이블과 매핑할 클래스는 @Entity 필수
- 기본 생성자 필수
- final 클래스, enum, interface, inner 클래스 사용 x
- 저장할 필드에 final 사용 x
데이터베이스 스키마 자동 생성
- DDL을 애플리케이션 실행 시점에 자동 생성
- 테이블 중심 -> 객체 중심
- 데이터베이스 방언을 활용해서 데이터베이스에 맞는 적절한 DDL 생성
- 이렇게 생성된 DDL은 개발 장비에서만 사용
- 생성된 DDL은 운영서버에서는 사용하지 않거나, 적절히 다듬은 후 사용
기억보다 기록, 난리보다 정리