JPA

JPA 소개

SQL 중심적인 개발의 문제점

•

DB 세계의 헤게모니

◦

관계형 DB

•

객체를 관계형 DB 에 저장

•

무한 반복, 지루한 코드(CRUD, 객체 → SQL, SQL→ 객체, 필드 추가 등)

•

SQL에 의존적인 개발을 피하기 어렵다

•

패러다임의 불일치

◦

객체 vs 관계형 DB

▪

상속

•

조회, 삽입 등 복잡하다.

▪

연관관계

•

참조 vs 외래 키

•

객체는 단방향, 외래키는 양방향 

▪

데이터 타입

▪

데이터 식별 방법

◦

객체 저장시

▪

RDB, NoSQL, File 등

◦

객체 SQL 매핑을 개발자가 함

JPA 소개

JPA는 표준 명세

JPA를 왜 사용해야 하는가?

생산성

persist, find, setName, remove 등

ii.

유지보수

iii.

패러다임의 불일치 해결

상속

알아서 insert 두개날림

연관관계

알아서 join 해서 날림

같은 트랜잭션에서 조회한 엔터티는 같다고 보장

성능 향상

1차 캐시와 동일성 보장

쓰기 지연

지연 로딩과 즉시 로딩

영속성 컨텍스트(pc)

•

엔터티를 영구 저장하는 환경

◦

db에 저장하는 것이 아니라 영속성 컨텍스트 라는 곳에 저장

•

em.persist(entity);

•

영속성 컨텍스트는 논리적인 개념

•

엔터티 매니저를 통해 영컨에 접근 

•

em 과 pc가 1:1(J2SE 환경)

•

em 과 pc가 n:1(J2EE, spring framework 같은 컨테이너 환경)

엔터티 생명 주기

•

비영속(new, transient)

◦

pc 와 전혀 관계가 없는 새로운 상태

•

영속(managed)

◦

pc 에 관리되는 상태

•

준영속(detached)

◦

pc 에 저장되었다가 분리된 상태

•

삭제

•

em.persist 하면 pc 에 저장(db 저장 x)

•

em.commit 할 때 쿼리가 날라감

PC 의 이점

•

1차 캐시 

•

동일성 보장

•

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

◦

pc 내부 쓰기 지연 SQL 저장소에 insert sql 생성

◦

이후 commit() 이 날아오면 flush() 로 insert sql 보냄

•

엔터티 수정 변경 감지(dirty checking)

◦

스냅샷으로 변경 감지

flush

•

PC 를 비우는 것이 아님

•

PC 의 변경 내용을 DB 에 동기화하는 것이 목적

detach(entity) vs clear()

•

특정 엔터티만 준영속 상태로 전환

•

pc 를 완전히 초기화

entity 매핑

•

unique 는 @column 말고 @table 이용하기!