[섹션 1, 섹션 2, 섹션 3] 헌치 제출합니다

[BETTERFUTURE4]

섹션 1 : JPA 소개

1. JPA 도입 배경

현재는 객체를 관계형DB에 저장하는 시대이다!

1) SQL 의존적 개발

• 지루한 코드
• 필드 추가시 해당 객체를 쓰는 모든 CRUD SQL을 수정

2) 패러다임의 불일치

• 객체지향의 특징을 제대로 활용 X

1] 객체 vs 관계형데이터베이스(RDB)

• 상속 : 객체는 상속 O, 관계형데이터베이스는 상속 X
• 연관관계 : 객체는 참조(reference: 단방향, 양방향시 순환참조 문제...?), 관계형데이터베이스는 PK/FK 로 join(양방향)
  • 객체와 DB 사이 불일치
  • 모델링 조회 시 일일이 데이터 연관관계 맻어주고 매핑해줘야 함

2] 객체 그래프 탐색

출처 : https://bros.tistory.com/m/16

• 객체 그래프 탐색 : 참조값으로 연결된 값(ex : team)을 조회
• DB 탐색 후 얻은 객체에, 진짜로 내가 원하는 필드가 채워져 있는가?
  • 중간에 참조가 끊어져 있을텐데...
• 엔티티를 신뢰할 수 X

3) 객체 동일성 보장 X

• 객체에서는 동일한 값들이 DB에서는 다른 엔티티가 됨

2. JPA란?

자바 진영의 ORM 표준 기술

1) ORM

• Object-relational mapping(객체 관계 매핑)
• 해당 프레임워크가 객체-관계형 DB 중간에서 매핑
• 대중적 언어 대부분은 ORM 기술 존재

2) JPA

• 구현체 프레임워크를 사용 : 하이버네이트(오픈소스)
• 인터페이스의 모음
  • JPA2.1 표준 명세를 위한 3가지 구현체
  • 하이버네이트, EclipseLink, DataNucleus

3) JPA의 장점

1] 생산성 향상

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

2] 유지보수

• 필드만 추가하면 됨, SQL은 JPA가 처리

3] 패러다임의 불일치 해결

• 위에서 언급한 상속, 연관관계, 그래프 탐색... 해결

4] 엔티티 계층을 신뢰

class MemberService {
    //...
    public void process() {
        Member member = memberDAO.find(memberId);
        member.getTeam(); //자유로운 객체 그래프 탐색
    }
}

5] 성능 최적화

• 1차 캐시와 동일성(identity) 보장
  • 같은 트랜잭션 같은 엔티티 -> 조회 성능 UP
  • Isolation Level ... Repeatable Read 보장
• 트랜잭션을 지원하는 쓰기 지연
  • 트랜잭션 커밋 순간, JDBC BATCH SQL 기능을 사용해서 한번에 SQL 전송
• 지연 로딩, 즉시 로딩 옵션 끄고 켤 수 있음
  • 지연 로딩 : 객체가 실제 사용될 때 로딩
  • 즉시 로딩: JOIN SQL로 한번에 연관된 객체까지 미리 조회

섹션 3 : 영속성 컨텍스트

• EntityManagerFactory : EntityManager 생성. 1개만 필요
• EntityManager : 엔티티의 CRUD 일 처리
  • 나중에 영속성 컨텍스트와 n대 1 관계가 될 수도 있지만, 기본적으론 1대1 관계

1. 영속성 컨텍스트(PersistContext)

• 엔티티를 영구 저장하는 환경
• EntityManager.persist(entity); 사용
• 엔티티 매니저를 통해 영속성 컨텍스트에 접근

1) 엔티티의 생명주기

1] 비영속(new/transient)

• jpa와 전혀 관계 없는 새로운 상태

Member member=new Member("1L", "헌치");

2] 영속(managed)

• 객체를 영속성 컨텍스트 안에 저장
• 그로 인해 영속성 컨텍스트가 해당 객체를 관리하는 상태

EntityManager em=emf.createEntityManager();
em.getTransaction().begin();
em.persist(member); //객체를 저장

3] 준영속(detached)

• 영속성 컨텍스트에서 저장되었다가 분리된 상태

em.detach(member);

4] 삭제(removed)

• 객체가 DB에서 삭제된 상태

em.remove(member);

2. 영속성 컨텍스트의 이점

1) 1차 캐시 코드 조회(사실 성능 이점이 크진 않음)

1. 조회 시 우선 1차 캐시에서 조회
2. 1차 캐시에 없으면 DB에서 조회
3. 조회된 값을 1차캐시에 저장
4. 반환

2) 영속 엔티티의 동일성 보장

• em.find로 가져온 두 값의 동일성을 보장한다.
• 1차 캐시로 반복 가능한 읽기(REPEATABLE READ) 등급의 트랜잭션 격리 수준을 데이터베이스가 아닌 애플리케이션 차원에서 제공...

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

1. transaction.begin(); : 트랜잭션 시작
2. em.persist(memberA); : SQL 저장소에 데이터들을 저장
3. transaction.commit(); : 커밋 시 한번에 DB에 전송

4) 변경 감지(Dirty Checking)

// 영속 엔티티 데이터 수정
memberA.setUsername("hi");
memberA.setAge(10);
//-> 커밋 시 자동으로 데이터 업데이트

• 현재 엔티티와 스냅샷(영속성 컨텍스트 최초에 들어온 값) 비교
• 플러시(커밋) 시 데이터에 변경이 일어났으면 자동 DB 업데이트

3. 플러시

• 영속성 컨텍스트의 변경 내용을 데이터베이스에 동기화
• 영속성 컨텍스트를 비우지는 않음
• 트랜잭션 단위로, 커밋 직전에만 동기화하면 됨!

1) 플러시 발생

1. 변경 감지
2. 수정된 엔티티를 바로 DB에 저장

2) 플러시 호출 방법

• em.flush() : 직접 호출(자주 안씀)
• 트랜잭션 커밋 시 자동 호출
• JPQL 쿼리 실행 시 자동 호출

3) 플러시 모드

• FlushModeType.AUTO: 커밋이나 쿼리실행 시 플러시(기본값)
• FlushModeType.COMMIT: 커밋 시 플러시
• 가급적 기본 설정 쓰자

4. 준영속

• 영속 상태의 엔티티가 영속성 컨텍스트에서 분리됨
• 이제 영속성 컨텍스트 기능 사용 X!

1) 준영속 상태 만드는 법

• em.detach(entity) : 특정 엔티티만 준영속 상태로 전환
• em.clear() : 영속성 컨텍스트를 완전히 초기화
• em.close() : 영속성 컨텍스트를 종료