스프링 데이터 JPA 분석

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

스프링 데이터 JPA가 제공하는 공통 인터페이스의 구현체는 org.springframework.data.jpa.repository.support.SimpleJpaRepository 이다.

 

@Repository 적용

• JPA 예외를 스프링이 추상화한 예외로 변환한다.
• JDBC를 JPA로 바꿔도 예외를 처리하는 매커니즘이 동일하다.

 

@Transactional 트랜잭션 적용

• JPA의 모든 변경은 트랜잭션 안에서 동작한다.
• 스프링 데이터 JPA는 변경(등록, 수정, 삭제) 메서드를 트랜잭션 처리한다.
• 서비스 계층에서 트랜잭션을 시작하지 않으면 리파지토리에서 트랜잭션 시작한다.
• 서비스 계층에서 트랜잭션을 시작하면 리파지토리는 해당 트랜잭션을 전파 받아서 사용한다.
• 그래서 스프링 데이터 JPA를 사용할 때 트랜잭션이 없어도 데이터 등록, 변경이 가능했음(사실은 트랜잭션이 리포지토리 계층에 걸려있는 것임)

 

@Transactional(readOnly = true)

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

 

save() 메서드

• 새로운 엔티티면 저장( persist )
• 새로운 엔티티가 아니면 병합( merge ) (select 쿼리를 한번 나감)

활용편에서 배운 변경감지와 merge를 통해 save가 구현되어 있다. 가급적 이면 merge를 사용하지말자.

 

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

 

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

• 식별자가 객체일 때 null로 판단한다. (Long)
• 식별자가 자바 기본 타입일 때 0으로 판단한다. (long)
• Persistable 인터페이스를 구현해서 판단 로직 변경이 가능하다.

 

문제점

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

그런데 JPA 식별자 생성 전략이 @Id 만 사용해서 직접 할당이면 이미 식별자 값이 있는 상태로 save() 를 호출한다. 따라서 이 경우 merge() 가 호출된다.

merge() 는 우선 DB를 호출해서 값을 확인하고, DB에 값이 없으면 새로운 엔티티로 인지하므로 매우 비효율 적이다.

만약 @GenerateValue를 사용하지 못하고 자신이 직접 id값을 지정해줘야 한다면 Persistable 를 사용해서 새로운 엔티티 확인 여부를 직접 구현하게는 효과적이다.

public class Item implements Persistable<String> {
 	@Id
 	private String id;
 
 	@CreatedDate
 	private LocalDateTime createdDate;
    
 	public Item(String id) {
 		this.id = id;
 	}
    
 	@Override
 	public String getId() {
 		return id;
 	}
    
 	@Override
 	public boolean isNew() { //직접 구현해주면 됨
 		return createdDate == null; // createDate 이게 null 인지 확인을 통해 들어왔는지 검사 가능
 	}
}

 

출처

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%EB%8D%B0%EC%9D%B4%ED%84%B0-JPA-%EC%8B%A4%EC%A0%84/dashboard

실전! 스프링 데이터 JPA - 인프런 | 강의