JPA 심화
👉 영속성 컨텍스트
- 엔티티를 영구 저장 하는 환경
# JPA 엔티티의 상태
- 비영속(New) : 영속성 컨택스트와 관계가 없는 새로운 상태
(해당 객체의 데이터가 변경되거나 말거나 실제 DB의 데이터와는 관련없고, 그냥 Java 객체인 상태)
// 엔티티를 생성
Member minsook = new Member();
member.setId("minsook");
member.setUsername("민숙");
- 영속(Managed) : 엔티티 매니저를 통해 엔티티가 영속성 컨텍스트에 저장되어 관리되고 있는 상태
(데이터의 생성, 변경등을 JPA가 추적하면서 필요하면 DB에 반영)
// 엔티티 매니저를 통해 영속성 컨텍스트에 엔티티를 저장
em.persist(minsook);
- 준영속(Detached) : 영속성 컨택스트에서 관리되다가 분리된 상태
// 엔티티를 영속성 컨택스트에서 분리
em.detach(minsook);
// 영속성 컨텍스트를 비우기
em.clear();
// 영속성 컨택스트를 종료
em.close();
- 삭제(Removed) : 영속성 컨택스트에서 삭제된 상태
em.remove(minsook)
# 영속성 컨텍스트는 어떻게, 왜 이렇게 설계되어있을까?
- 1차 캐시라는 것을 가지고 있다.
1. find(”memberB”)와 같은 로직이 있을 때 먼저 1차 캐시를 조회.
2. 있으면 해당 데이터를 반환.
3. 없으면 그 때 실제 DB로 “SELECT * FROM….” 의 쿼리를 내보냄.
4. 그리고 반환하기 전에 1차캐시에 저장하고 반환.
-> (memberB를 find 하는 요청이 다시 들어와도 굳이 DB로 다녀올 필요가 없다.)
- “쓰기 지연 SQL 저장소”가 있다.
1. memberA, memberB를 영속화 하고
2. entityManager.commit() 메서드를 호출하면
3. 내부적으로 쓰기 지연 SQL 저장소에서 Flush가 일어나고
4. “INSERT A”, “INSERT B”와 같은 쓰기 전용 쿼리들이 DB로 흘러들어간다.
- DirtyChecking을 통해 데이터의 변경을 감지해서 자동으로 수정해준다.
1. 사실 1차 캐시에는 DB의 엔티티의 정보만 저장하는것이 아니다.
2. 해당 엔티티를 조회한 시점의 데이터의 정보를 같이 저장해둔다.
3. 그리고 엔티티객체와 조회 시점의 데이터가 다르다면 변경이 발생했다고 알 수 있음.
4. 해당 변경 부문을 반영 할 수 있는 UPDATE 쿼리를 작성.
- 데이터의 어플리케이션 단의 동일성을 보장
Member member1 = em.find(Member.class, "minsook");
Member member2 = em.find(Member.class, "minsook");
System.out.println(member1 == member2) => true
# 기본 엔티티 매핑 관련
- @Entity
1. `**기본 생성자**`는 필수!
2. final 클래스, enum, interface 등에는 사용 할 수 없다.
3. 저장할 필드라면 final을 사용하면 안된다.
- @Table”관련!
1. 엔티티와 매핑할 테이블의 이름
- @Clumn
1. 객체 필드를 테이블 컬럼에 매핑하는데 사용
2. 생략 가능
- @Enumerated
1. Java Enum을 테이블에서 사용한다고 생각.
🙋♂️ 소감 :
JPA 알면 알수록 고마운 녀석이다.
자동으로 해주는만큼 그 내부 로직은 복잡하다고 하는데... 일단은 그냥 고마운 녀석으로 알고 넘어가기....ㅎ
😈 아는 내용이라고 그냥 넘어가지 않기! 😈
'❤️🔥TIL (Today I Learned)' 카테고리의 다른 글
[TIL] 2022-12-14(34day) (0) | 2022.12.15 |
---|---|
[TIL] 2022-12-14(33day) (1) | 2022.12.14 |
[TIL] 2022-12-12(31day) (0) | 2022.12.12 |
[TIL] 2022-12-09(30day) (0) | 2022.12.11 |
[TIL] 2022-12-08(29day) (0) | 2022.12.08 |
댓글