Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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
- 컨테이너
- AWS
- Spring Data JPA
- 지연 로딩
- Routing Key
- MSA
- Web
- JPQL
- JWT
- redis
- mybatis
- 페이징
- securitycontextholderfilter
- docker
- Spring Container
- 쿠버네티스
- JdbcTemplate
- 스프링 부트
- @Transactional
- JPA
- docker compose
- 서블릿 컨테이너
- DLQ
- @ComponentScan
- CORS
- Dead Letter Queue
- kafka
- Spring
- DI
- dockerhub
Archives
- Today
- Total
look-forest
스프링 데이터 JPA 분석 본문
스프링 데이터 JPA가 제공하는 공통 인터페이스의 구현체
org.springframework.data.jpa.repository.support.SimpleJpaRepository

@Repository 적용
- JPA 예외를 스프링이 추상화한 예외로 변환 (하부 기술이 바껴도 비즈니스 로직에 변경이 없도록 유연한 설계 지원)
@Transactional(readOnly = true)
- 데이터를 단순히 조회만 하고 변경하지 않는 트랜잭션에서 readOnly = true 옵션을 사용하면 flush를 생략해서 약간의 성능 향상을 얻을 수 있음
@Transactional 트랜잭션 적용
- JPA의 모든 변경은 트랜잭션 안에서 동작
- 스프링 데이터 JPA는 변경(등록, 수정, 삭제) 메서드를 트랜잭션 처리
- 서비스 계층에서 트랜잭션을 시작하지 않으면 리파지토리에서 트랜잭션 시작
- 서비스 계층에서 트랜잭션을 시작하면 리파지토리는 해당 트랜잭션을 전파 받아서 사용
- 그래서 스프링 데이터 JPA를 사용할 때 트랜잭션이 없어도 데이터 등록, 변경이 가능했음(사실은 트랜잭션이 리포지토리 계층에 걸려있는 것임)
save() 메서드
- 새로운 엔티티면 저장 (persist)
- 새로운 엔티티가 아니면 병합(merge)
새로운 엔티티를 구별하는 방법
entityInformation.isNew(entity)
새로운 엔티티를 판단하는 기본 전략
- 객체일 때 : 식별자 null 여부로 판단
- 자바 기본 타입일 때 : 식별자 0 여부로 판단
JPA 식별자 생성 전략이 @GenerateValue 면 save() 호출 시점에 식별자가 없으므로 새로운 엔티티로 인식해서 정상 동작한다. 그런데 JPA 식별자 생성 전략이 @Id 만 사용해서 직접 할당이면 이미 식별자 값이 있는 상태로 save() 를 호출한다. 따라서 이 경우 merge() 가 호출된다. merge() 는 우선 DB를 호출해서 값을 확인하고, DB에 값이 없으면 새로운 엔티티로 인지하므로 매우 비효율적이다.
이럴 때는 Persistable 를 구현해서 isNew 오버라이딩으로 새로운 엔티티 확인 여부를 직접 정의하는 것 효과적이다.


참고 자료 & 이미지 출처
실전! 스프링 데이터 JPA (김영한 님)
'JPA > Spring data JPA' 카테고리의 다른 글
| 확장 기능 (2) | 2024.10.20 |
|---|---|
| 다양한 편의 기능 (0) | 2024.10.19 |
| 공통 인터페이스 기능 (0) | 2024.10.19 |