[자바 ORM 표준 JPA 프로그래밍 2] ORM 기술, JPA

• JPA (Java Persistence API) - 자바 진영의 ORM 기술 표준
  
  •  JPA는 오픈소스에서 출발한 자바 표준 명세
    • EJB(자바 표준) → 하이버네이트(오픈소스) → JPA (자바 표준) 
    • JPA 버전
      • JPA 1.0(JSR 220) 2006년 : 초기 버전. 복합 키와 연관관계 기능이 부족
      • JPA 2.0(JSR 317) 2009년 : 대부분의 ORM 기능을 포함, JPA Criteria 추가
      • JPA 2.1(JSR 338) 2013년 : 스토어드 프로시저 접근, 컨버터(Converter), 엔티티 그래프 기능이 추가
  • JPA는 인터페이스의 모음 (JAVA의 표준 인터페이스) 
    • JPA 2.1 표준 명세를 구현한 3가지 구현체 : 하이버네이트, EclipseLink, DataNucleus (JPA는 하이버네이트 구현체를 거의 사용)

 

•  ORM : Object-relational mapping (객체 관계 매핑)
  • 객체는 객체대로 설계, 관계형 데이터베이스(RDB)는 관계형 데이터베이스대로 설계
  • ORM 프레임워크가 객체와 RDB를 중간에서 매핑

 

---

• JPA는, 애플리케이션과 JDBC 사이에서 동작

JPA

 

• JPA 동작 - 저장

JPA 동작 - 저장

• JPA 동작 - 조회

JPA 동작 - 조회

 

---

• JPA를 왜 사용해야 하는가? 
• SQL 중심적인 개발에서 객체 중심으로 개발
  1. 생산성
  2. 유지보수
  3. 패러다임의 불일치 해결
  4. 성능
  5. 데이터 접근 추상화와 벤더 독립성
  6. 표준

 

---

1. 생산성 - JPA와 CRUD

• 저장:  jpa.persist(member) 
• 조회:  Member member = jpa.find(memberId) 
• 수정:  member.setName(“변경할 이름”) 
• 삭제:  jpa.remove(member)  

 

---

2. 유지보수

• 기존: 필드 변경시 모든 SQL 수정
• JPA: 필드만 추가하면 됨, SQL은 JPA가 처리

tel 필드만 추가해주면, SQL은 JPA가 처리해준다!

 

---

3.  JPA와 패러다임의 불일치 (JPA와 상속 , JPA와 연관관계 , JPA와 객체 그래프 탐색 , JPA와 비교하기) 해결 

 

[자바 ORM 표준 JPA 프로그래밍 -1] SQL 중심적인 개발의 문제점 (tistory.com)

[자바 ORM 표준 JPA 프로그래밍 -1] SQL 중심적인 개발의 문제점

 

---

• JPA와 상속

• 저장
  • 개발자는  jpa.persist(album);  만 하면 된다.
  • 나머진 JPA가 처리
    • INSERT INTO ITEM ... INSERT INTO ALBUM ... 
• 조회
  • 개발자는  Album album = jpa.find(Album.class, albumId);   
  • 나머진 JPA가 처리
    • SELECT I.*, A.* FROM ITEM I JOIN ALBUM A ON I.ITEM_ID = A.ITEM_ID 

 

---

• JPA와 연관관계, 객체 그래프 탐색
  • 연관관계 저장
    • member.setTeam(team); jpa.persist(member);
  • 객체 그래프 탐색
    • Member member = jpa.find(Member.class, memberId); Team team = member.getTeam();

/** 신뢰할 수 있는 엔티티, 계층 */
class MemberService {
 	...
 	public void process() {
 		Member member = memberDAO.find(memberId);
 		member.getTeam(); //자유로운 객체 그래프 탐색
 		member.getOrder().getDelivery();
 	}
}

 

---

• JPA와 비교하기
  • 동일한 트랜잭션에서 조회한 엔티티는 같음을 보장

String memberId = "100";
Member member1 = jpa.find(Member.class, memberId);
Member member2 = jpa.find(Member.class, memberId);

member1 == member2; //같다.

 

---

4. JPA의 성능 최적화 기능

• 1차 캐시와 동일성(identity) 보장
• 트랜잭션을 지원하는 쓰기 지연 (transactional write-behind)
• 지연 로딩 (Lazy Loading)

 

---

• 1차 캐시와 동일성 보장
  1.  같은 트랜잭션 안에서는 같은 엔티티를 반환 → 약간의 조회 성능 향상
  2.  DB Isolation Level이 Read Commit이어도 애플리케이션에서 Repeatable Read 보장

 

• SQL 1번만 실행

String memberId = "100";
Member m1 = jpa.find(Member.class, memberId); //SQL
Member m2 = jpa.find(Member.class, memberId); //캐시
/** SQL 쿼리 처음 1번만 실행하고, 그 이후부턴 SQL 실행하지 않고 JPA가 가진 메모리 상에서 반환 */

println(m1 == m2) //true

 

---

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

 

• INSERT
  1. 트랜잭션을 커밋할 때까지 INSERT SQL을 모았다가
  2. JDBC BATCH SQL 기능을 사용해서 한번에 SQL 전송

transaction.begin(); // [트랜잭션] 시작

em.persist(memberA);
em.persist(memberB);
em.persist(memberC);
//여기까지 INSERT SQL을 데이터베이스에 보내지 않는다.

//커밋하는 순간 데이터베이스에 INSERT SQL을 모아서 보낸다.
transaction.commit(); // [트랜잭션] 커밋

• UPDATE
  1. UPDATE, DELETE로 인한 로우(ROW)락 시간 최소화
  2. 트랜잭션 커밋 시 UPDATE, DELETE SQL 실행하고, 바로 커밋

transaction.begin(); // [트랜잭션] 시작

changeMember(memberA); 
deleteMember(memberB); 
비즈니스_로직_수행(); //비즈니스 로직 수행 동안 DB 로우 락이 걸리지 않는다. 

//커밋하는 순간 데이터베이스에 UPDATE, DELETE SQL을 보낸다.
transaction.commit(); // [트랜잭션] 커밋

 

---

• 지연 로딩과 즉시 로딩
  • 지연 로딩: 객체가 실제 사용될 때 로딩
  • 즉시 로딩: JOIN SQL로 한번에 연관된 객체까지 미리 조회

• 성능 최적화를 위해
  • 보통 지연 로딩으로 세팅을 해두고, 필요한 부분만 즉시 로딩으로 세팅

 

---

→ ORM은, 객체와 RDB 두 기둥위에 있는 기술이다.