[스프링 데이터 JPA] 6. 스프링 데이터 JPA 분석

 

1️⃣ 스프링 데이터 JPA 구현체 분석 

org.springframework.data.jpa.repository.support.SimpleJpaRepository

-> 스프링 데이터 JPA가 제공하는 공통 인터페이스의 구현체 

 

SimpleJpaRepository

@Repository

: 이 어노테이션을 사용하면 스프링 빈으로 등록되어 컴포넌트 스캔의 대상이 되고, JPA 예외를 스프링이 추상화한 예외로 변환해주는 역할도 한다. 

-> 스프링이 강조하는 큰 장점 중 하나라고 할 수 있는데 JPA 를 사용하다가 어떤 이유로 JDBC 등으로 변경했다고 해도 예외 같은걸 스프링 관련 예외로 알아서 변환해주기 때문에 구현체가 바뀌어도 로직은 동일하게 돌아가도록 설계되어있다.

 

@Transactional

: 트랜잭션 적용, JPA의 모든 변경은 트랜잭션 안에서 동작 

스프링 데이터 JPA는 변경(등록, 수정, 삭제) 메서드를 트랜잭션 처리 

- 서비스 계층에서 트랜잭션을 시작하지 않으면 리파지토리에서 트랜잭션 시작 

- 서비스 계층에서 트랜잭션을 시작하면 리파지토리는 해당 트랜잭션을 전파 받아서 사용 

그래서 스프링 데이터 JPA를 사용할 때 트랜잭션 없어도 데이터 등록, 변경이 가능했음 ( 사실 트랜잭션이 리포지토리 계층에 걸려있기 때문) 

 

@Transactional(readonly = true)

: 데이터를 단순히 조회만 하고 변경하지 않는 트랜잭션에서는 readOnly = true 옵션을 사용하면 플러시를 생략해서 약간의 조회 성능 향상을 얻을 수 있다. 

따라서 전체에는 readOnly = true를 걸어주고, 데이터 변경이 있는 메소드에는 @Transactional 어노테이션을 걸어서 해당 메소드에서만 데이터 변경이 일어나도록 설정해주면 약간의 조회 성능 향상을 얻을 수 있다. 

(기본이 readOnly = false) 

 

 

save()

- 새로운 엔티티면 저장 -> persist()

- 새로운 엔티티가 아니면 병합 -> merge()

 

❗️ merge 사용은 조심해야 하는게 데이터를 모두 갈아 끼우기 때문에 이걸 수정할 때 사용하면 큰일이다. 있던 데이터까지 뒤집어 쓸 수 있기 때문!! 그러므로 수정을 할 때는 변경 감지를 사용해야 하고, merge는 영속 상태가 아닌 엔티티에 대해서 다시 영속 상태로 만들때 ~ 

뭐 이런 상황에서만 사용해야 한다. ( merge를 직접 사용하는 경우는 거의 없다고 한다.) 

 

 

 

 

2️⃣ 새로운 엔티티를 구별하는 방법 

 

새로운 엔티티를 판단하는 기본 전략 

- 식별자가 객체일 때는 Null 로 판단  (ex) Long) 

- 식별자가 자바 기본 타입일 때는 0으로 판단 (ex) long -> 기본 타입은 null 이 안되니까~) 

- Persistable 인터페이스를 구현해서 판단 로직 변경 가능 

 

Persistable

 

Item

예제를 위해서 Item 엔티티를 만들었다.

이때 pk 값을 Long 이 아닌 어떤 이유로 String으로 만들었다고 하자. 그런데 이때 @GeneratedValue 를 생략하고 직접 생성해주는 것으로 변경했다. 

그리고 객체를 생성할 때 id 값을 미리 지정하도록 했다. 

 

ItemRepositoryTest

그리고 간단한 테스트로 save 하는 테스트이다. 

근데 새로운 엔티티를 판단하는 전략으로 우선 객체의 식별자가 null 일때 새로운 객체로 판단한다고 했는데 

지금 Item에는 'A' 로 식별자 값이 주어져있기 때문에 처음에 jpa가 새로운 객체로 판단을 못하고, merge() 를 호출한다. 

 

그러므로 이 테스트를 돌려보면 

우선 select를 해서 식별자가 'A'인 item을 우선 데이터베이스에서 조회를 하고, 이때 없기 때문에 그제서야 insert를 한다는 치명적인 단점이 있다. 

-> merge는 persist에 비해 쿼리를 한번 더 날리기 때문에 비교적 비효율적이다. 

 

 

⭐️ 참고 ⭐️ 

JPA 식별자 생성 전략이 @GeneratedValue 면 save() 호출 시점에 식별자가 없으므로 새로운 엔티티로 인식해서 정상 동작한다. 

그런데 JPA 식별자 생성 전략이 @Id만 사용해서 직접 할당이면 이미 식별자 값이 있는 상태로 save() 를 호출하다. 따라서 이 경우에는 merge()가 호출된다.  merge()는 우선 DB를 호출해서 값을 확인하고, DB에 값이 없으면 새로운 엔티티로 인지하므로 매우 비효율적이다.  따라서 Persistable를 사용해서 새로운 엔티티 확인 여부를 직접 구현하는게 효과적이다. 

 

참고로 등록시간(@CreatedDate)를 조합해서 사용하면 이 필드로 새로운 엔티티 여부를 편리하게 확인할 수 있다. 

(@CreatedDate에 값이 없으면 새로운 엔티티로 판단) 

 

Persistable 구현 

Persistable 인터페이스를 상속받고 구현하면 된다. 

이때 @CreatedDate를 사용해서 이 값이 null 이면 새로운 값이라고 판단하는 것이다. 

그리고 이때 Auditing을 사용하니까 @EntityListener(AuditingEntityListener.class)를 추가해줘야 한다~~

 

이러고 다시 테스트를 돌려보면 

이번에는 select해서 먼저 DB 조회를 하지 않고 바로 새로운 엔티티로 판단하고 insert 한 쿼리를 확인해 볼 수 있다.