1. 오늘 한 것
- 스프링 강의 듣기
2. 오늘 배운 것
-
ORM
- Object Relational Mapping
- 객체와 DB를 매핑해주는 도구
-
JPA
- Java Persistence API
- 자바 ORM 기술에 대한 표준 명세
-
Hibernate
- JPA는 표준 명세이고, 이를 실제 구현한 프레임워크 중 사실상 표준
- 스프링 부트는 기본적으로 'Hibernate' 구현체를 사용 중
- 사실상 표준(de facto) : 보통 기언간 경쟁을 통해 시장에서 결정되는 비 공식적 표준
-
@GeneratedValue(strategy = GenerationType.IDENTITY)
auto_increment 해주는 옵션
-
영속성 컨텍스트 ( Persistence Context )
- Persistence는 영속성, 지속성 이라는 뜻
- 객체가 생명(객체가 유지되는 시간)이나 공간(객체의 위치)을 자유롭게 유지하고 이동할 수 있는 객체의 성질
- 쉽게 표현하면 Entity 객체를 효율적으로 쉽게 관리하기 위해 만들어진 공간
-
JPA의 트랜잭션
- 트랜잭션은 DB데이터들의 무결성과 정합성을 유지하기 위한 하나의 논리적 개념
- 가장 큰 특징은 여러 개의 SQL이 하나의 트랜잭션에 포함될 수 있다는 점
이때, 모든 SQL이 성공적으로 수행이 되면 DB에 영구적으로 변경을 반영하지만 SQL 중 단 하나라도 실패한다면 모든 변경을 되돌림
-
영속성 컨텍스트의 기능
- 1차 캐시
- 쓰기 지연 저장소 ( ActionQueue )
- 변경 감지 ( Dirty Checking )
-
1차 캐시 (캐시 저장소)
- 영속성 컨텍스트 내부적으로 캐시 저장소를 지님
- em.persist(memo); 메서드가 호출되면 memo Entity 객체를 캐시 저장소에 저장
- 캐시 저장소는 키 값을 갖는 맵 자료구조를 가짐
-
Entity 조회
- em.find(Memo.class, 1); 메서드로 캐시저장소를 먼저 조회하고 존재하지 않을 경우 DB SELECT 조회 후 캐시 저장소에 저장하고 반환 함
-
1차 캐시 장점
- DB 조회 횟수를 줄임
- 객체 동일성 보장 : DB row 한개당 객체 한개가 사용되는 것을 보장
-
Entity 삭제
- em.remove(entity); 메서드로 캐시 저장소 조회 후 없다면 DB 조회해서 캐시 저장소에 저장
- 저장한 다음이나 캐시저장소에 Entity가 있다면 삭제할 Entity를 DELETED 상태로 만든 후 트랜잭션 commit 후 delete SQL이 DB에 요청
-
쓰기 지연 저장소 (actionQueue)
- JPA는 트랜잭션처럼 SQL을 모아서 한번에 DB에 반영하기 위해 SQL을 모아두고 있다가 트랜잭션 commit 후 한번에 DB에 반영
-
em.flush()
- 트랜잭션 commit 후 추가적인 동작이 있는데 바로 em.flsuh();
- flush 메서드는 영속성 컨텍스트의 변경 내용들을 DB에 반영하는 역할을 수행, 즉 쓰기 지연 저장소의 SQL들을 DB에 요청하는 역할을 수행
- commit은 EntityTransaction이지만 flush는 EntityManager
- 트랜잭션 설정을 하지 않고 flush()를 호출하면
-> no transaction is in progress 메시지와 함께 TransactionRequiredException 오류가 발생 - Insert, Update, Delete 즉, 데이터 변경 SQL을 DB에 요청 및 반영하기 위해서는 트랜잭션이 필요
Select는 단순 조회이므로 필수는 아님, 필요할 수는 있음
-
변경 감지 (dirtyChecking)
- update 쿼리를 값이 바뀔때마다 날리면 비효율적
- 값이 변경되면 entityEntry에 있는 loadedState의 초기 값과 entityInstance의 값을 비교해 값이 다르면 쓰기 지연 저장소에 update SQL을 저장 함
- flush 혹은 commit 시 한꺼번에 반영
3. 느낀 점
- 공부할 내용 혹은 공부하고 싶은 내용들이 많은데 하루하루 시간이 금방가고 너무 짧게 느껴진다. 조금 더 집중해서 더 많이 배우자!
개발