Notice
Recent Posts
Recent Comments
Link
250x250
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
Tags
- 서버
- 디자인 패턴
- Next.js
- 자바스크립트
- 프론트엔드
- jsp
- 코드테스트
- jpa
- 자바
- BACK-END
- 오라클
- 프런트엔드
- java
- 프로그래머스
- 알고리즘
- 백엔드
- 스프링부트
- 쿼리
- JavaScript
- 스프링
- 정리
- oracle
- 코드 테스트
- MySQL
- SQL
- 미니정리
- web
- spring
- node.js
- 데이터베이스
Archives
- Today
- Total
참치코더의 꿈 메모장
JPA / IDENTITY 전략 VS SEQUENCE 전략 비교 정리 본문
728x90

IDENTITY 전략
- DB(AUTO_INCREMENT)가 insert 실행 시점에 PK를 만들어줌
- 따라서 em.persist(entity) 하면 JPA는 즉시 insert 쿼리를 날림 (flush 강제 발생)
- 그 insert 결과로 생성된 PK를 가져와서 엔티티 객체에 채워 넣음
-> 이러한 이유들 때문에 배치 insert(모여서 한 번에 쓰기)가 잘 안 됨.
-> JPA 1차 캐시나 영속성 컨텍스트에서 ID를 바로 알아야 하니까 insert를 바로 실행 한다.
SEQUENCE 전략
- 오라클 / PostgreSQL처럼 DB가 시퀀스 객체를 지원하는 경우 사용할 수 있다.
- em.persist(entity) 하면 insert 전에 먼저 시퀀스에서 PK를 뽑아온다.
- JPA가 그 값을 엔티티에 할당한다.
- 그리고 나서 insert SQL을 모아두고, flush 시점에 한 번에 insert할 수 있다.
-> 즉, ID는 persist 시점에 미리 확보하고, 실제 insert는 flush 시점에 모아서 실행이 가능하다.
-> 그래서 batch insert 최적화가 가능하고, IDENTITY보다 효율적이다.
flush 발생 시점
1. 트랜잭션 commit 할 때
2. JPQL 쿼리 실행 전
3. 명시적으로 em.flush() 호출 시
728x90
'JPA' 카테고리의 다른 글
| JPA - 양방향 매핑 과 설정 방법 정리 (0) | 2025.10.08 |
|---|---|
| JPA / 단방향 엔티티 연관관계(多 : 一) 정리 (0) | 2025.10.06 |
| JPA / 데이터 생성 시간 , 수정 시간 컬럼 자동 저장 방법(코드 위주) (0) | 2025.10.04 |
| JPA / Entitymanager와 영속성 컨텍스트 관계 정리 (0) | 2025.10.01 |
| JPA / 기본적인 동작과정 미니정리(코드 위주) (0) | 2025.09.30 |
Comments