[섹션 1, 섹션 2, 섹션 3] 토르 제출합니다.

[injoon2019]

1. 왜 JPA를 써야 하는가

1. 관계형 데이터베이스와 객체지향 패러다임의 불일치
   1. 객체지향의 특징을 제대로 활용하지 못한다.
2. 일일이 데이터를 다 불러와서 개발자가 직접 연관 관계를 맺어주고 객체를 매핑해주는 것은 부담스럽다.
3. 객체 그래프 탐색 불가능 문제
   1. 엔티티에 대한 신뢰 문제
4. 객체의 동일성이 보장되지 않는다.
   1. 자바의 컬렉션이었으면 당연히 됐을
5. JdbcTemplate에서는 필드가 하나 추가 됐을 경우 유지보수가 엉망이다.

2. JPA 구동 방식

1. 설정 정보를 조회하고
2. EntityManagerFactory를 생성한다. 이 EntityManagerFactory는 하나만 생성해서 애플리케이션 전체 공유
3. 요청마다 EntityManager를 생성한다. 이 Entitymanager는 쓰레드간에 공유하지 않는다. 사용하고 닫아야 한다.

고객의 요청이 올때마다 EntityManager를 만들고, EntityManager는 커넥션 풀을 이용한다.

3. 영속성 컨텍스트

EntityManager마다 영속성 컨텍스트를 가지고 있다 (나중에 스프링에서는 N:1로 이용한다)

3.1 엔티티의 생명주기

1. 비영속 - jpa와 전혀 관계 없는 상태
2. 영속 - 영속성 컨텍스트가 관리하는 상태
3. 준영속 - 영속성 컨텍스트에서 분리
4. 삭제

3.2 영속성 컨텍스트의 이점

1. 1차 캐시

코드에서 persist를 했을 때 실제 DB에 변경이 생기는 것이 아니라 엔티티를 영속화하는 것이다. 영속 컨텍스트 캐시에서 변경이 생긴다. 조회를 하면 우선 1차캐시에서 찾고, 없으면 DB에서 가져온다. 캐시에서 가져오므로 DB에 쿼리가 안나간다.

2. 동일성 보장

캐시에서 꺼내기 때문에 동일성 보장이 가능해진다.

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

쓰기 지연 SQL 저장소에 쌓아놨다가 커밋을 하는 순간 모아뒀던 것을 한번에 날린다.

4. 변경 감지

커밋하기전 엔티티와 스냅샷(영속성 컨텍스트에 최초로 들어온 상태)를 비교한다. 커밋되는 시점에 비교해서 데이터에 변경이 일어났으면 반영해준다.