이 녀석은 그냥 인터페이스고 실제 이 인터페이스를 구현한 구현체가 있다. 물론, 스프링 데이터 JPA가 구현체를 미리 만들어서 제공해준다.
그 구현체의 이름은 SimpleJpaRepository이다.
package org.springframework.data.jpa.repository.support;
import ...
@Repository
@Transactional(
readOnly = true
)
public class SimpleJpaRepository<T, ID> implements JpaRepositoryImplementation<T, ID> {...}
클래스가 굉장히 크기 때문에 여기다 그 내용을 다 적을 순 없고 직접 들어가서 확인해 보길 바란다.
확인해보면 정말 별 게 없다. 우리가 다 이전에 순수 JPA로 해봤던 코드들이 그대로 여기에도 적용되어 있다.
이런것을 보면, 잘 만든 라이브러리의 주인이 우리가 될 수도 있다는 가슴 설레는 기분이 든다.
그리고 이렇게 스프링 데이터 JPA가 만들어주는 구현체에 이미 @Repository, @Transactional(readOnly = true)가 들어있기 때문에 JpaRepository를 상속받는 인터페이스를 우리가 만들때 @Repository를 굳이 붙이지 않아도 됐던 것이고, 서비스에 @Transactional을 걸지 않아도 스프링 데이터 JPA를 사용해서 공통 인터페이스를 사용하면 쓰기 작업도 원활히 됐던 것이다. 물론 이 내용은 모두 스프링 데이터 JPA를 사용한다는 가정하에 말이다.
예시로 delete()를 보면 이렇게 생겼다.
@Transactional
public void delete(T entity) {
Assert.notNull(entity, "Entity must not be null");
if (!this.entityInformation.isNew(entity)) {
if (this.entityManager.contains(entity)) {
this.entityManager.remove(entity);
} else {
Class<?> type = ProxyUtils.getUserClass(entity);
T existing = (T)this.entityManager.find(type, this.entityInformation.getId(entity));
if (existing != null) {
this.entityManager.remove(this.entityManager.merge(entity));
}
}
}
}
뭐 딱히 다른게 없다! 결국은 EntityManager.remove() 호출하는 것이다.
자자, 그리고 변경 감지를 사용해야 한다는 말을 하면서 데이터를 저장하는게 아니라 변경 시에는 save()를 호출하는 게 아니라고 여러번 얘기했는데 이 save() 코드도 보자. 진짜 뭐가 없다.
@Transactional
public <S extends T> S save(S entity) {
Assert.notNull(entity, "Entity must not be null");
if (this.entityInformation.isNew(entity)) {
this.entityManager.persist(entity);
return entity;
} else {
return (S)this.entityManager.merge(entity);
}
}
자, 엔티티가 새로운 엔티티라면 persist()를 호출하고 그렇지 않다면(데이터를 변경하는 거라면) merge()를 호출하고 있다. 이렇기에 데이터를 변경 시 save()를 호출하는 게 아니라 변경감지를 사용해야 한다고 말하는 것이다. 변경감지를 사용해야 하는 이유는 크게 3가지가 있다.
어차피 merge()도 결국엔 영속성 컨텍스트에 올려서 데이터를 변경한 다음 변경감지로 데이터를 바꾼다.
위 1번에 따르면, merge()를 호출하면 영속성 컨텍스트에 올린다고 했는데 그럼 데이터베이스에서 해당 데이터를 조회하는 과정이 일어나는 것 아닌가? 맞다. 데이터베이스에 이 변경하려는 데이터의 레코드가 있는지 확인하기 위해 조회 쿼리가 나간다.
조회한 데이터에 전달한 변경할 데이터를 담은 엔티티의 모든 값으로 덮어씌운다. null이 있었다면? null로 덮어씌운다.
데이터를 변경할 때 save() 호출하지 말자. 절대!!
새로운 엔티티를 구별하는 방법
바로 위에서 본 save() 메서드에서, 새로운 엔티티라면 persist()를 호출하고, 그게 아니라면 (즉, 데이터베이스에 이미 저장된 데이터라면) merge()를 호출하는 것을 보았다. 그런데 말이다. 새로운 엔티티인지 어떻게 판단할까?
이 내용이 꽤나 중요하기 때문에 집중해야 한다. 우선 결론부터 말하면 이렇다.
새로운 엔티티를 판단하는 기본 전략
식별자(PK)가 객체(Long과 같은)타입일 때 null이라면 새로운 엔티티라고 판단
식별자(PK)가 자바 기본 타입(long)일 때 0이라면 새로운 엔티티라고 판단
이게 무슨말인지 코드를 통해서 조금 더 자세히 알아보자.
Item
package cwchoiit.datajpa.entity;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.Id;
@Entity
public class Item {
@Id
@GeneratedValue
private Long id;
}
아주 간단한 엔티티 하나를 만든다. 식별자 필드 딱 하나만 있으면 된다.
주의 깊게 볼 부분은 @GeneratedValue와 Long 타입이다.
@GeneratedValue는 사용하는 데이터베이스에게 PK 생성을 위임하는 방식인데 이렇게 하면 EntityManager.persist()를 호출했을 때는 아직 데이터베이스에 저장하기 전이기 때문에 이 Id값이 없다. 즉 null이다.
이렇게 했을 때 아까 위에서 본 SimpleJpaRepository의 save()는 어떻게 동작할까?
한번 디버깅을 해보자.
이 isNew(entity)는 어떤 판단을 할까?
우선 브레이크 포인트에 걸렸을 때는 다음과 같이 당연히 id값은 null이다. 아직 데이터베이스에 저장하기 전이니까 말이다.
그래서 persist()를 호출하는 코드를 그대로 수행하게 된다.
이처럼, 식별자가 객체(Long)일 때는 null인 경우 새로운 엔티티라고 판단한다.
그러면 자바 기본 타입인 long같은 경우 값을 세팅 안하면 0이 기본값이라서 0일때 새로운 엔티티라고 판단한다고 했던것이다.
아니, 근데 이건 너무 쉬운데 왜 이 내용이 중요하다고 했을까? 지금의 경우는 식별자를 @GeneratedValue로 설정했을 때 이야기다. 만약, 이 방식을 사용하지 않고 개발자가 직접 아이디를 세팅한다고 한다면 어떻게 될까? 그러니까 엔티티를 다음과 같이 작성하는 것이다.
Item
package cwchoiit.datajpa.entity;
import jakarta.persistence.Entity;
import jakarta.persistence.Id;
import lombok.AccessLevel;
import lombok.AllArgsConstructor;
import lombok.NoArgsConstructor;
@Entity
@AllArgsConstructor
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Item {
@Id
private Long id;
}
@Id만 사용해서 직접 식별자 값을 할당하는 경우에는 당연히 이미 식별자 값이 있는 상태로 save()를 호출한다. 아래 코드처럼 말이다.
이전 포스팅에서, 그냥 메서드 시그니처만 만들어도 자동으로 스프링 데이터 JPA가 쿼리를 만들어주는 놀라운 기능을 제공한다고 했었다! 이게 사실일까?!
쿼리 메서드
이 기능을 쿼리 메서드라고 표현한다. 순수 JPA를 사용해서 만약 유저를 찾는데, 특정 유저이름 조건과 나이 조건을 부합하는 유저를 찾는 쿼리를 순수 JPA로 만든다고 해보자.
public List<Member> findByUsernameAndAgeGreaterThan(String username, int age) {
return em.createQuery("SELECT m FROM Member m WHERE m.username = :username AND m.age > :age", Member.class)
.setParameter("username", username)
.setParameter("age", age)
.getResultList();
}
그럼 이런식으로 직접 JPQL을 작성해야 한다. 물론 어려운게 아니다. 귀찮은 거지.
그런데, 저 코드를 그냥 메서드 시그니처 하나로 알아서 만들어준다면? 개발자들의 개발자 경험은 기가막히게 올라갈 것이다.
그런데, 이 방식의 가장 큰 문제점 중 하나는 여기서 조건이 한 두개 정도만 더 추가되도 메서드 이름이 너무 길어진다는 것이다. 생각해보자. 만약 나이 조건과 이름 조건 말고 팀 조건도 있고 등급 조건도 있으면 아마 이렇게 생겨먹을 것이다.
List<Member> findByUsernameAndAgeGreaterThanAndFindByTeamEqualsAndFindByGradeEquals(String username, int age, Team team, Grade grade);
으악이다. 이걸 누가 보고 좋다 할 수 있겠나?
대신, 조건 2개 정도안에서는 정말 정말 좋은 기능이다.
그럼 이런 경우엔 어떻게 해결하면 될까? 직접 JPQL을 사용할 수 있게도 지원해준다.
JPA NamedQuery
이 방법은 위의 문제를 해결해주지만 결론부터 말하면 이 기능은 거의 사용하지 않으니 그냥 이런게 NamedQuery구나? 하고 넘어가면 된다. 바로 아래 코드를 보자.
Member 엔티티
@Entity
@Getter
@Builder
@AllArgsConstructor
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@ToString(of = {"id", "username", "age"})
@NamedQuery(
name = "Member.findByUsername",
query = "SELECT m FROM Member m WHERE m.username = :username"
)
public class Member {...}
엔티티를 정의한 클래스에 @NamedQuery 라는 애노테이션을 달고, 거기에 쿼리에 대한 명칭과 쿼리를 직접 작성해줄 수 있다.
쿼리에 명칭을 부여한다고 해서 NamedQuery이다.
그리고 이걸 어떻게 사용하면 되냐? 바로 다음 코드를 보자.
우선, 순수 JPA만을 사용했을 때 방법이다. 순수 JPA 레포지토리에서 다음과 같이 작성할 수 있다.
package cwchoiit.datajpa.repository;
import cwchoiit.datajpa.entity.Member;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;
import java.util.List;
import java.util.Optional;
@Repository
@RequiredArgsConstructor
public class MemberJpaRepository {
private final EntityManager em;
...
public List<Member> findByUsername(String username) {
return em.createNamedQuery("Member.findByUsername", Member.class)
.setParameter("username", username)
.getResultList();
}
}
em.createNamedQuery() 라는 메서드가 있는데 이게 바로 아까 만든 NamedQuery의 이름을 가져다가 사용하는 방법이다.
그런데 생각해보면, 굳이 이걸 왜써? 라는 생각이 드는게 그냥 JPQL을 바로 직접 사용하면 되는것 아닌가? 순수 JPA는 그게 맞다. 그런데 스프링 데이터 JPA는 좀 편리하게 사용할 수가 있다.
이 @Query(name = "...")이 없어도 동작한다! 왜 그럴까? 스프링 데이터 JPA가 규칙이 있는데 이게 NamedQuery인지를 먼저 확인하기 위해 "엔티티.메서드명"으로 된 NamedQuery를 찾는게 첫번째 하는 작업이다.
그래서 Member.findByUsername 으로 된 NamedQuery를 찾는데 아까 내가 만들었으니 그걸 그대로 가져다가 적용하는 것이다.
만약, 찾았는데 없다면 위에서 배운 쿼리 메서드를 만드려고 시도한다.
그러나, 이 방법은 깊이 있게 알 필요가 없다. 왜냐하면 이 NamedQuery는 너무 불편해서 거의 사용하지 않는다. 왜 불편하냐면 이 다음에 말할 최고의 막강한 기능이 있다. 그걸 다 사용하기 때문에 이건 거의 사용하지 않는다. 그래도 이 NamedQuery의 좋은 점도 있다. 좋은 점은 쿼리에 문제가 있으면 컴파일 오류를 뱉어준다는 점이다. 다음 코드를 보자.
순수 JPA로 만든 레포지토리를 보면, 이 JPQL은 결국 다 문자열이다.
이건 다 문자열이기 때문에 저 문자열로 만들어진 JPQL에 문법적 오류가 있어도 컴파일 시점에 그것을 확인할 수가 없다. 그래서 컴파일 시 문제가 안 생기는데 만약, 유저가 이 쿼리를 호출해야 하는 어떤 작업을 하는 순간 빵! 하고 런타임 에러가 발생하겠지.
그건 좋지 않다.
그런데, 이 NamedQuery는 문자열이긴 한데 컴파일 시점에 문법 오류를 잡아준다! 다음 코드를 보자!
저기 보면, `m.us123123ername`으로 오타가 발생했다. 이 상태에서 컴파일 하면 컴파일 오류가 난다!
NamedQuery는 이런 장점이 있기도 하다. 그런데 결국 안쓴다. 왜냐? 다음에 배울 녀석은 이 장점을 그대로 가짐과 동시에 훨씬 더 편하게 사용할 수 있다!
@Query, 레포지토리 메소드에 쿼리 직접 정의
이 방법이 최고의 방법이다. 바로 코드로 보자.
package cwchoiit.datajpa.repository.springdatajpa;
import cwchoiit.datajpa.entity.Member;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.Query;
import org.springframework.data.repository.query.Param;
import java.util.List;
import java.util.Optional;
public interface MemberRepository extends JpaRepository<Member, Long> {
Optional<Member> findByUsername(@Param("username") String username);
@Query("SELECT m " +
"FROM Member m " +
"WHERE m.username = :username AND m.age > :age")
List<Member> findByUsernameAndAgeGreaterThan(@Param("username") String username, @Param("age") int age);
}
이렇게 @Query로 바로 JPQL을 작성할 수 있다. 얼마나 편리한가?
그리고 이 기능 역시 컴파일 시 문법 오류를 잡아준다.
보다시피, `m.user123123name` 이라고 잘못 입력했을 때 이걸 컴파일 하면 바로 아래와 같이 컴파일 오류를 뱉어낸다.
그래서 쿼리 메서드를 사용하는데 조건이 여러개가 늘어나는 경우에는 이 기능을 잘 사용하기를 권장한다!
그리고, 이 @Query를 사용하면서, 단순히 값 하나만 조회하거나 DTO로 변환하여 조회할 수도 있다.
단순히 값 하나만을 조회
@Query("SELECT m.username FROM Member m")
List<String> findUsernames();
m.username처럼 원하는 값 하나를 SELECT절을 채우면 끝이다.
DTO로 조회
우선, DTO로 조회하려면 DTO가 당연히 있어야 하겠지. DTO를 아래와 같이 만들었다.
MemberDto
package cwchoiit.datajpa.dto;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;
@Data
@NoArgsConstructor
@AllArgsConstructor
public class MemberDto {
private String username;
private String teamName;
private int age;
}
아래와 같이 DTO로 조회하면 된다. 순수 JPA에서 했던 방식이랑 동일하다. `new` 키워드를 사용해서 패키지명까지 다 작성하는 방식.
@Query("SELECT new cwchoiit.datajpa.dto.MemberDto(m.username, t.name, m.age) FROM Member m JOIN m.team t")
List<MemberDto> findMembersWithDto();
근데 이게 순수 JPA를 사용하는 경우 단건 조회 시 결과가 없으면 NoResultException을 발생시킨다. 그런데 스프링 데이터 JPA는 결과가 없다고 에러를 발생시키는 게 맞아? 하면서 이 경우 자기들이 내부적으로 try - catch로 이 예외를 잡아서 null을 반환해버리게 만들어줬다. 그래서 이것에 대해 갑론을박이 있다. 내 개인적인 생각으로도 예외보다는 null이 맞다고 보는데 이게 자바8 이전에 있던 갑론을박이고 자바8 이후로 뭐가 나왔냐?! Optional 이라는 아주 기특한 녀석이 나왔기 때문에 단건 조회는 그냥 무조건 Optional을 사용하는 게 좋다.
그리고, 단건 반환 타입인데 결과가 2건 이상인 경우 스프링 데이터 JPA고 순수 JPA고 그냥 무조건 NonUniqueResultException이 발생한다.
참고로, 이 뿐만 아니라 여러 반환 타입이 있다. 이는 공식 문서를 참고해보면 되는데 가장 많이 사용되는 타입이 저 세가지라고 보면 된다.
순수 JPA 페이징과 정렬
JPA에서는 페이징을 어떻게 할까? JPA는 페이징 처리를 굉장히 편하게 할 수가 있는데, 우선 순수 JPA로 페이징하는 방법을 보고 스프링 데이터 JPA가 페이징을 어떻게 하는지도 보자!
public List<Member> findByPage(int age, int offset, int limit) {
return em.createQuery("SELECT m FROM Member m WHERE m.age = :age ORDER BY m.username DESC", Member.class)
.setParameter("age", age)
.setFirstResult(offset)
.setMaxResults(limit)
.getResultList();
}
public long totalCount(int age) {
return em.createQuery("SELECT COUNT(m) FROM Member m WHERE m.age = :age", Long.class)
.setParameter("age", age)
.getSingleResult();
}
JPA는 setFirstResult(), setMaxResults() 메서드를 지원한다. 이게 MySQL로 치면 offset, limit에 해당하는 부분이다.
그래서 굉장히 간단하게 페이징 처리를 할 수 있다.
그리고, 전체 개수를 가져오는 쿼리도 만들어야 한다. 그래서 totalCount()라는 메서드를 만들고 전체 개수를 가져오는 JPQL을 구현했다.
테스트 코드로 잘 동작하는지 확인해보자.
@Test
void paging() {
memberJpaRepository.save(new Member("memberA", 10));
memberJpaRepository.save(new Member("memberB", 10));
memberJpaRepository.save(new Member("memberC", 10));
memberJpaRepository.save(new Member("memberD", 10));
memberJpaRepository.save(new Member("memberE", 10));
List<Member> members = memberJpaRepository.findByPage(10, 0, 3);
long totalCount = memberJpaRepository.totalCount(10);
//페이지 계산 공식 적용...
// totalPage = totalCount / size ...
// 마지막 페이지 ...
// 최초 페이지 ...
assertThat(members.size()).isEqualTo(3);
assertThat(totalCount).isEqualTo(5);
}
나이가 10살인 회원을 조회한다. 그리고 그 쿼리에 대한 페이징 처리를 했다. offset은 0, limit은 3이다.
순수 JPA를 사용하면, 데이터와 전체 개수를 가져오면 페이징 계산을 따로 해줘야하는 번거로움이 있다. 그런데 이 부분을 스프링 데이터 JPA가 아주 쉽게 처리해준다. 이후에 봐보자!
테스트 실행 결과는 아주 잘 동작한다.
실행 결과
스프링 데이터 JPA 페이징과 정렬
스프링 데이터 JPA를 사용하면 페이징 처리가 아주 기가막히다. 그런데 이건, 스프링 데이터 JPA가 아니라 Spring Data가 표준으로 제공하는 것이라 구현한 어떤 데이터 접근 기술이든 공통 사항이다.
정렬 기능 → org.springframework.data.domain.Sort
페이징 기능 (내부에 Sort 포함) → org.springframework.data.domain.Pageable
패키지를 보면 알겠지만, data.jpa가 아니라 data에서 끝난다. 스프링 데이터 JPA뿐 아니라, Redis, MongoDB 등 어떤걸 사용해도 동일한 인터페이스라는 이야기다. 정말 잘 만들었다는 생각이 든다.
그리고 추가적으로 특별한 반환 타입이 있다.
org.springframework.data.domain.Page → count 쿼리 결과를 포함하는 페이징
org.springframework.data.domain.Slice → count 쿼리 없이 다음 페이지만 확인 가능 (내부적으로 limit + 1로 조회)
저 Slice라는 건 뭐냐면, 전체 개수는 없는데 그 모바일에서 보면, 화면을 쭉 내리다보면 보이는 [더보기] 버튼 같은 페이징 처리에 사용되는 것이다. 그래서 사용자가 더보기 버튼을 누르면 (누르지 않아도 되는 경우도 있고) 추가적으로 데이터를 가져오는 그런 방식이다. 그래서 limit + 1을 조회해서 limit까지 데이터를 보여주고 +1 했을때 데이터가 있는 경우 [더보기] 버튼을 보여지게 하는 그런 방식이다.
타입을 Page로 받고, 파라미터로 Pageable만 추가하면 끝이다! 그리고 스프링 데이터 JPA는 쿼리 메서드 기능이 있어서 findByAge하면 넘겨받은 age 파라미터랑 같은 age를 가지는 데이터를 가져온다.
물론, 당연히 원하는 JPQL을 작성하는 @Query()를 사용해도 된다.
@Test
void paging() {
memberRepository.save(new Member("memberA", 10));
memberRepository.save(new Member("memberB", 10));
memberRepository.save(new Member("memberC", 10));
memberRepository.save(new Member("memberD", 10));
memberRepository.save(new Member("memberE", 10));
int age = 10;
PageRequest pageRequest = PageRequest.of(0, 3, Sort.by(Sort.Direction.DESC, "username"));
Page<Member> members = memberRepository.findByAge(age, pageRequest);
// Contents
List<Member> content = members.getContent();
// Total Count
long totalCount = members.getTotalElements();
// Page Number (현재 페이지 번호)
int pageNumber = members.getNumber();
// Total Pages (전체 페이지 수)
int totalPages = members.getTotalPages();
// 첫번째 페이지인지
boolean isFirst = members.isFirst();
// 다음 페이지가 있는지
boolean hasNext = members.hasNext();
assertThat(content.size()).isEqualTo(3);
assertThat(totalCount).isEqualTo(5);
assertThat(pageNumber).isEqualTo(0);
assertThat(totalPages).isEqualTo(2);
assertThat(isFirst).isTrue();
assertThat(hasNext).isTrue();
}
Pageable에 들어갈 파라미터를 만들기 위해 PageRequest.of(...)로 PageRequest 객체 하나를 만든다.
PageRequest가 Pageable을 구현했기 때문에 아무 문제없이 저 자리에 들어갈 수 있다.
그리고, PageRequest.of(0, 3, Sort.by(Sort.Direction.DESC, "username")) 이라고 하면, 현재 페이지 0, 조회할 데이터 수 3, `username`을 기준으로 내림차순으로 정렬한다는 뜻이다. 참고로 가져온 데이터를 기준으로 내림차순으로 정렬하는게 아니라, 내림차순으로 정렬된 데이터를 페이지 0번에서 데이터 3개를 가져온다.
이렇게 해서 데이터 가져오면 어떤것들을 할 수 있냐? 데이터, 전체 개수, 현재 페이지 번호, 전체 페이지 수, 첫번째 페이지인지 여부, 다음 페이지가 있는지에 대한 여부를 모두 알 수 있다!
참고로, 첫번째 페이지는 1부터 시작이 아니라 0부터 시작이다.
Slice 사용
이번에는 Slice를 사용해보자!
MemberRepository
package cwchoiit.datajpa.repository.springdatajpa;
import cwchoiit.datajpa.dto.MemberDto;
import cwchoiit.datajpa.entity.Member;
import org.springframework.data.domain.Page;
import org.springframework.data.domain.Pageable;
import org.springframework.data.domain.Slice;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.Query;
import org.springframework.data.repository.query.Param;
import java.util.List;
import java.util.Optional;
public interface MemberRepository extends JpaRepository<Member, Long> {
Page<Member> findByAge(int age, Pageable pageable);
@Query("SELECT m FROM Member m WHERE m.age = :age")
Slice<Member> findByAgeWithSlice(@Param("age") int age, Pageable pageable);
}
메서드 이름을 바꿔야 했어서 @Query()를 사용했다. 아까 위에서 말했듯, 쿼리 메서드뿐 아니라 @Query로 직접 JPQL을 작성할 수도 있다!
테스트 코드로 테스트 해보자!
@Test
void paging_slice() {
memberRepository.save(new Member("memberA", 10));
memberRepository.save(new Member("memberB", 10));
memberRepository.save(new Member("memberC", 10));
memberRepository.save(new Member("memberD", 10));
memberRepository.save(new Member("memberE", 10));
int age = 10;
PageRequest pageRequest = PageRequest.of(0, 3, Sort.by(Sort.Direction.DESC, "username"));
Slice<Member> members = memberRepository.findByAgeWithSlice(age, pageRequest);
// Contents
List<Member> content = members.getContent();
// Page Number (현재 페이지 번호)
int pageNumber = members.getNumber();
// 첫번째 페이지인지
boolean isFirst = members.isFirst();
// 다음 페이지가 있는지
boolean hasNext = members.hasNext();
assertThat(content.size()).isEqualTo(3);
assertThat(pageNumber).isEqualTo(0);
assertThat(isFirst).isTrue();
assertThat(hasNext).isTrue();
}
Slice는 전체 개수나, 전체 페이지 수를 가져오지 않는다! 그냥 이 방식은 다음 페이지가 있는지 없는지만 판단하고 있으면 [더보기] 버튼 만들어서 사용자에게 보여주면 된다.
이게 스프링 데이터가 아니라 다른 기술이었다면 이 방식으로 변경하기 위해 코드를 아예 다시 작성했어야 했을텐데 스프링 데이터의 도움을 받아서 그냥 타입만 Page → Slice로 변경하면 끝이다. 놀랍지 않은가?
전체 Count 쿼리는 고민할 거리가 많다.
위에서 Page를 사용한 경우를 보았다. 얘는, 전체 카운트 개수도 뽑아준다. 근데 같은 쿼리로 내보내서 카운트를 가져오는데 이게 생각보다 간단치 않은 문제다. 왜냐하면, 데이터가 정말 많은 경우에 전체 카운트 개수를 가져오는 건 꽤나 무거운 행위이다. 예를 들어, 데이터가 100만건이 있다고 생각했을 때 이 전체 개수를 가져오는 쿼리는 굉장히 무겁다. 반면, 페이징 해서 데이터를 짤라서 가져오는 건 아무 문제가 되지 않지만 말이다.
그럼 만약, 이런 쿼리가 있다고 해보자.
SELECT m FROM Member m LEFT JOIN m.team t
이건 지금 멤버와 팀을 조인하는 쿼리이다. 이대로 Page 타입의 쿼리를 날리면 전체 개수를 가져오는 것도 이 쿼리로 나간다.
그런데 생각해보면, 지금 멤버를 기준으로 LEFT JOIN 할 때 다른 WHERE조건도 없고 딱 이 쿼리 그대로라면 전체 카운트는 저 쿼리 대신 아래와 같은 쿼리를 날려도 완전히 동일한 개수를 가져온다.
SELECT COUNT(m.username) FROM Member m
곰곰히 생각해보면 이렇게 날려도 동일한 전체 개수를 가져온다는 것을 알 것이다. 그럼 카운트 쿼리는 이게 더 좋지 않을까? 조인을 하면 그만큼 낭비를 하는 것인데 말이다.
그래서! 스프링 데이터 JPA에서는 쿼리와 카운트 쿼리를 분리할 수가 있다!
@Query(value = "SELECT m FROM Member m LEFT JOIN m.team t", countQuery = "SELECT COUNT(m) FROM Member m")
Page<Member> findByAge(int age, Pageable pageable);
이렇게 카운트 쿼리를 최적화할 수도 있는 것이다. 이건 굉장히 중요하고 최적화 아이템 중 하나다.
아까 작성해본 PageRequest이고, 여기에 세번째 파라미터로 Sort.by(...)해서 정렬 기준을 작성해서 사용했다.
그런데, 이 정렬 조건이 꽤나 복잡해 지는 경우가 있을 수가 있다. 그런 경우에는 이게 이걸로 풀리지가 않는다. 그래서 그냥 JPQL로 풀어버리면 된다. 아래와 같이 말이다.
@Query("SELECT m FROM Member m WHERE m.age = :age ORDER BY m.username DESC")
Slice<Member> findByAgeWithSlice(@Param("age") int age, Pageable pageable);
페이징 처리를 해도 엔티티를 DTO로 변환하는 것은 필수!
int age = 10;
PageRequest pageRequest = PageRequest.of(0, 3, Sort.by(Sort.Direction.DESC, "username"));
Page<Member> members = memberRepository.findByAge(age, pageRequest);
REST API의 경우, 이 members 그대로 내보내면 큰일난다! 엔티티는 절대 외부로 노출하지 말자고 여러번 말했다.
그리고, 이 엔티티를 아주 간단하게 DTO로 변경할 수가 있다.
Page<Member> members = memberRepository.findByAge(age, pageRequest);
Page<MemberDto> membersDto = members.map(m -> new MemberDto(m.getUsername(), m.getTeam().getName(), m.getAge()));
이렇게 간단하게 map()을 사용해서 DTO로 변환하면 그대로 Page<MemberDto>로 변경할 수 있다.
벌크성 수정 쿼리
여러건의 데이터를 한번에 수정하는 쿼리를 날리는 것 역시 지원한다. 순수 JPA부터 해보자.
public int bulkAgePlus(int age) {
return em.createQuery("UPDATE Member m SET m.age = m.age + 1 WHERE m.age >= :age")
.setParameter("age", age)
.executeUpdate();
}
별거 없다. 그냥 executeUpdate()를 호출하면 끝이다.
스프링 데이터 JPA에서는 어떻게 해야할까?
MemberRepository
package cwchoiit.datajpa.repository.springdatajpa;
import cwchoiit.datajpa.dto.MemberDto;
import cwchoiit.datajpa.entity.Member;
import org.springframework.data.domain.Page;
import org.springframework.data.domain.Pageable;
import org.springframework.data.domain.Slice;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.Modifying;
import org.springframework.data.jpa.repository.Query;
import org.springframework.data.repository.query.Param;
import java.util.List;
import java.util.Optional;
public interface MemberRepository extends JpaRepository<Member, Long> {
...
@Modifying
@Query("UPDATE Member m SET m.age = m.age + 1 WHERE m.age >= :age")
int bulkAgePlus(@Param("age") int age);
}
쿼리 날리는 건 똑같은데, @Modifying 애노테이션을 꼭 붙여줘야 한다. 그래야 스프링 데이터 JPA는 아 이게 업데이트 쿼리를 날리는 구나를 인지할 수 있다.
근데 이 벌크성 쿼리를 날리는걸 어떻게 하냐가 문제가 아니다! 벌크성 쿼리는 조심해야 할 부분이 하나 있다. 순수 JPA든, 스프링 데이터 JPA든 벌크성 쿼리는 영속성 컨텍스트를 무시하고 바로 데이터베이스에 업데이트 쿼리를 빵! 날려버린다. 근데 이게 상황에 따라 다르겠지만 만약, 벌크성 쿼리 대상이 되는 레코드가 이미 영속성 컨텍스트에 관리되는 상태라면 실제 데이터베이스의 해당 레코드와 영속성 컨텍스트가 관리하는 해당 레코드의 데이터 불일치가 일어난다.
생각해보자. 영속성 컨텍스트는 쓰기 지연 기능이 있기 때문에 트랜잭션이 완전히 끝나는 시점에 쓰기 쿼리가 나간다. 그래서 트랜잭션이 살아있는 시점에는 쓰기 쿼리가 안 나가는 상태인데 이 상태 어느 순간에 벌크성 쿼리를 날리면 영속성 컨텍스트에 보관되고 있는 데이터는 변경되지 않고 데이터베이스에 직접적으로 적용되기 때문에 데이터베이스에 있는 데이터와 영속성 컨텍스트에 있는 데이터가 값이 달라질 수가 있다. 그래서 결론적으로는, 벌크성 쿼리를 날리면 무조건 플러시, 클리어를 해줘야한다.
저기서도 플러시가 핵심이 아니라, 클리어가 핵심이다. 플러시는 바로 위에서 말한 쓰기 지연 쿼리가 있는 경우 이 쿼리는 당연히 날려줘야 하니까 플러시를 호출해서 쓰기 지연 쿼리를 날리는 데 의의가 있는것이고, 클리어를 해줘야 영속성 컨텍스트가 관리하고 있는 모든 레코드가 정리되고 깨끗해진다.
근데, 스프링 데이터 JPA의 공통 인터페이스에는 플러시는 있지만 클리어는 없다. 이 경우에 어떻게 하면 되냐면, 방법은 두가지 정도가 있는데 첫번째 방법은 EntityManager를 주입받으면 된다. 주입 받아서 이렇게 작성하면 된다.
2024-12-13T12:01:39.214+09:00 DEBUG 50911 --- [ Test worker] org.hibernate.SQL :
select
m1_0.member_id,
m1_0.age,
m1_0.team_id,
m1_0.username
from
member m1_0
where
m1_0.username=?
member = Member(id=5, username=memberE, age=51)
51살로 잘 찍힌다.
그런데, 이건 굉장히 비효율적이다. 어떤 방법이 있냐면, 이렇게 해버리면 끝이다.
@Modifying(clearAutomatically = true, flushAutomatically = true)
@Query("UPDATE Member m SET m.age = m.age + 1 WHERE m.age >= :age")
int bulkAgePlus(@Param("age") int age);
@Modifying 애노테이션에는 clearAutomatically, flushAutomatically 속성이 있다.
@EntityGraph
지연로딩을 해결하기 위해 페치 조인을 사용하는 데 가끔 JPQL을 작성하기가 귀찮을때가 있다.
그럴때, 이 @EntityGraph를 이용하면 조금 더 편하게 페치 조인을 사용하는 것처럼 할 수 있다.
예시일뿐이다. 스프링 데이터 JPA가 만들어준 기본 findAll()을 사용하면 페치 조인이 먹히질 않는다. 그리고 연관 객체를 가져올때 N+1 문제가 발생하는데, 그러기가 싫고 페치 조인으로 한번에 다 가져오고 싶은데 JPQL을 작성하기 귀찮다! 하면 이렇게 하면 된다.
저 attributePaths = {...} 에 들어가는 게 연관 객체들이다.
근데 이렇게 기존에 있는 메서드를 재정의하는 방식 말고, 내가 새로 만든 메서드를 사용하긴 하는데 이것도 페치 조인을 해야 하긴 하는데 JPQL을 작성하기 귀찮은 경우에 이렇게도 작성할 수 있다.
@Query("SELECT m FROM Member m")
@EntityGraph(attributePaths = {"team"})
List<Member> findMemberEntityGraph();
@Query로 가장 간단하게 JPQL을 작성하고 페치 조인을 작성하는 부분은 빼버린 다음에 @EntityGraph 애노테이션을 사용하면 된다.
근데 난 굳이?란 생각은 든다. 그냥 아래와 같이 하면 되지 않나.
@Query("SELECT m FROM Member m JOIN FETCH m.team")
List<Member> findMemberEntityGraph();
근데 이런 경우는 그냥 JPQL 작성으로 한번에 하는게 더 편하고, 위에 경우처럼 스프링 데이터 JPA가 제공하는 공통 메서드를 재정의해서 사용하고 싶은 경우나 아니면 쿼리 메서드를 사용할때는 꽤나 유용할 것 같다. 아래와 같이 말이다.
이 Hint와 Lock은 자주 사용하는 것은 아니고 알아두면 될 정도만 이해하고 있으면 된다.
Hint
이 힌트라는건 어떤거냐면, 예를 들어 데이터베이스에서 어떤 데이터를 가져오고 그걸 엔티티로 우리가 사용할 때 정말 죽었다가 깨어나도 이 데이터는 변경할 필요도 없고 영속성 컨텍스트에 스냅샷을 가지고 있을 이유가 하나도 없다면 사용해볼 법한 기능이다. 결국 변경 감지든 1차 캐시든 어쨌든간에 영속성 컨텍스트가 그 데이터를 가지고 관리한다는 것은 메모리를 사용한다는 것이고 사용하지 않아도 될 메모리를 사용하는 것보단 사용 안할 수 있다면 안하는게 더 좋으니까 "스냅샷 가지고 있지 말아라"라고 JPA에게 알려주는 거라고 생각하면 된다.
레포지토리에 @QueryHints 애노테이션을 달아서, 위와 같이 작성해주면 이 메서드로 가져오는 멤버를 영속성 컨텍스트가 관리하지 않는다. 그래서 오로지 정말 READ의 목적만 있는 경우에는 이런 방법을 고려해봐도 좋다. 성능도 메모리를 쓰는것보단 덜 잡아 먹을테니.
테스트 코드로 테스트를 해보면 어떤 말인지 알 수 있을 것이다.
@Test
void hint() {
Member memberA = memberRepository.save(new Member("memberA", 10));
entityManager.flush();
entityManager.clear();
Member findMember = memberRepository.findReadOnlyMemberByUsername("memberA");
findMember.setUsername("memberB");
}
이렇게 작성하면 변경감지 기능으로 인해 해당 유저의 이름을 변경하는 쿼리를 날려야 한다. 기본적으로는 그게 맞는데 저렇게 @QueryHint로 readOnly를 설정하면 영속성 컨텍스트가 관리하지 않게 되어 변경 감지도 하지 않는다.
실행 결과
읽기만 하고 업데이트 쿼리는 없다.
Lock
락 같은 경우에는 뭐냐면, SELECT로 데이터를 가져올 때 FOR UPDATE 구문을 사용하는 것이다. 내가 읽은 데이터를 내가 커넥션을 반납하기 전에 (다른 말로 커밋하기 전에) 다른 커넥션에서 해당 데이터를 업데이트 치지 못하도록 하는 방법인데, 거의 보통은 사용하지 않는다. 특히나 트래픽이 많고 유저수가 많고 활발한 서비스는! 그런데 이런게 있다는것 정도만 알아두자.
스프링 데이터 JPA가 제공하는 인터페이스만으로 개발이 가능하면 아무런 문제가 없다. 그냥 그대로 쭉 사용해도 된다. 그런데 가끔은 정말 복잡한 동적 쿼리나 통계형 쿼리를 짜야하는 경우도 있다. 그런 경우에는 스프링 데이터 JPA의 공통 인터페이스가 제공하는 기능으로는 충분하지 않을 것이다. QueryDsl을 사용해야 할 때도 있고, NativeSQL을 작성해야 할 수도 있다.
이럴땐 두 가지 방법이 있다. 사용자 정의 레포지토리를 구현하거나 아예 통계형(쿼리형) 레포지토리를 직접 만들면 된다. 말보단 코드로!
별게 아니다. 그냥 나만의 인터페이스를 만들면 된다. 그리고 그 인터페이스에서 정의할 메서드도.
MemberRepositoryCustomImpl
package cwchoiit.datajpa.repository.springdatajpa;
import cwchoiit.datajpa.entity.Member;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import java.util.List;
@RequiredArgsConstructor
public class MemberRepositoryCustomImpl implements MemberRepositoryCustom {
private final EntityManager em;
@Override
public List<Member> findMemberCustom() {
return em.createQuery("SELECT m FROM Member m", Member.class).getResultList();
}
}
그 다음 이걸 구현할 구현체를 만들면 된다. 여기서는 예시이기 때문에 내용은 의미가 없지만 이렇게 하면 된다는 것이다. 보통은 이렇게 할 땐 QueryDsl을 사용해서 QueryDsl용 레포지토리 구현할때 많이 사용한다.
그래서 저 코드가 QueryDsl용 코드가 되면 된다.
이렇게 만든 인터페이스와 구현체를 스프링 데이터 JPA가 제공하는 공통 인터페이스가 상속받으면 된다. 다음과 같이 말이다.
public interface MemberRepository extends JpaRepository<Member, Long>, MemberRepositoryCustom {...}
이렇게 하면 끝이다.
근데 착각하면 안되는 게 있다. 이 과정이 절대 필수가 아니다. 이렇게 해도 된다는 것이지 이렇게 안해도 상관이 전혀 없다. 스프링 데이터 JPA가 제공하는 공통 인터페이스가 제공해주는 기능으로 충분하면 이 과정 필요없다. 그리고 특정 화면에서만 사용되는 복잡한 쿼리를 다룰때는 그냥 레포지토리를 만들면 된다. 그 안에서 QueryDsl을 사용하던 네이티브 쿼리를 작성하던 그건 개발하는 사람의 몫이고 반드시 이렇게 스프링 데이터 JPA가 제공하는 공통 인터페이스가 상속받도록 만들 필요는 없다는 것이다.
그러니까 이렇게 만들면 된다는 것이다.
package cwchoiit.datajpa.repository.springdatajpa;
import org.springframework.stereotype.Repository;
@Repository
public class MemberQueryRepository {
// QueryDsl 사용
// nativeSQL 사용
// ...
}
이렇게 나만의 레포지토리를 만들고 @Repository 애노테이션을 붙여서 스프링 빈으로 등록시킨 다음에 사용하는 곳에서 주입받아서 사용해도 아무런 문제가 없다는 말이다.
그리고 이 방식이 더 효율적이고 가시성이 좋을수도 있다. 위에서 말한 스프링 데이터 JPA가 제공하는 공통 인터페이스가 상속받게 만들면 오히려 핵심 쿼리(CRUD)와 쿼리형 레포지토리가 전부 짬뽕이 되서 가시성이 떨어질 수도 있기 때문이다.
Auditing
이 내용은 꽤나 중요하고 실무에서도 거의 무조건 사용하는 기능이다. 다른건 아니고 데이터베이스에 레코드 하나를 추가하거나 업데이트할 때, 누가 생성하고 수정했고, 그 시간이 어떻게 되는지?를 자동으로 넣어주는 방법이다.
우선, 이 기능을 사용하려면 다음과 같이 엔트리 클래스에 @EnableJpaAuditing 애노테이션을 넣어줘야한다.
@EntityListeners(AuditingEntityListeners.class) 애노테이션을 반드시 붙여줘야한다.
@MappedSuperclass 애노테이션 역시 반드시 붙여줘야 한다.
@CreatedDate, @LastModifiedDate, @CreatedBy, @LastModifiedBy 애노테이션을 각 필드에 붙여주면 된다.
이렇게 해 준 다음에 사용할 엔티티가 이 BaseEntity를 상속받으면 끝이다.
@Entity
public class Member extends BaseEntity {...}
한가지 유념할 부분은, @CreatedBy, @LastModifiedBy는 저렇게 애노테이션만 붙이면 다 되는게 아니라 한가지 작업을 더 해줘야 한다. 아래와 같이 말이다.
@Bean
public AuditorAware<String> auditorProvider() {
return () -> Optional.of(UUID.randomUUID().toString());
}
우선 빈으로 AuditorAware를 등록해줘야 한다. 그리고 반환값은 이제 이 엔티티를 생성하거나 수정한 사용자의 이름이나 아이디 정도면 적당할 것 같은데 지금은 그런 정보가 없고 실제 서비스라면, Spring Security를 사용하면 현재 로그인 한 사용자 정보를 가져올 수 있고 Http Session을 사용한다면 이 세션으로도 로그인 한 사용자 정보를 가져올 수 있을것이다. 그것을 반환하면 된다.
요 기능은 굉장히 유용하고 운영에 있어서 매우 많은 도움을 주는 데이터이다. 그래서 꼭 참고하길 바란다!
Web 확장 - 도메인 클래스 컨버터
결론부터 말하면, 쓰지 말거나 최소한으로 사용할 것을 권장한다. 코드로 바로 보자.
MemberController
package cwchoiit.datajpa.controller;
import cwchoiit.datajpa.entity.Member;
import cwchoiit.datajpa.repository.springdatajpa.MemberRepository;
import jakarta.annotation.PostConstruct;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequiredArgsConstructor
public class MemberController {
private final MemberRepository memberRepository;
@GetMapping("/members/{id}")
public String getMember(@PathVariable Long id) {
return memberRepository.findById(id)
.map(Member::getUsername)
.orElse(null);
}
}
컨트롤러가 있을 때, PathVariable로 ID값을 받으면 그 값으로 엔티티를 찾아내는 방법은 굉장히 일반적이다.
그래서 저렇게 멤버를 찾아서 멤버의 이름을 반환하거나 못 찾으면 null을 반환하는 아주 간단한 코드가 있다고 쳐보자.
이 코드를 스프링 데이터 JPA가 컨버터를 적용해주는데 아래와 같이 할 수 있단 뜻이다.
package cwchoiit.datajpa.controller;
import cwchoiit.datajpa.entity.Member;
import cwchoiit.datajpa.repository.springdatajpa.MemberRepository;
import jakarta.annotation.PostConstruct;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequiredArgsConstructor
public class MemberController {
private final MemberRepository memberRepository;
@GetMapping("/members/{id}")
public String getMember(@PathVariable Long id) {
return memberRepository.findById(id)
.map(Member::getUsername)
.orElse(null);
}
@GetMapping("/members2/{id}")
public String getMember(@PathVariable("id") Member member) {
return member.getUsername();
}
}
비교를 위해 기존의 코드를 남겨두었다. `/member2/{id}` 를 보면, @PathVariable로 ID를 받을 때 Member 타입으로 받으면 스프링 데이터 JPA는 이 받아온 아이디를 통해 바로 데이터베이스의 해당 ID를 가지고 있는 멤버를 뽑아준다.
당연히 파라미터 이름이 다르니까 @PathVariable("id") 이렇게 작성해야 한다.
실행 결과
GET http://localhost:8080/members2/1
HTTP/1.1 200
Content-Type: text/plain;charset=UTF-8
Content-Length: 7
Date: Wed, 18 Dec 2024 10:44:41 GMT
memberA
Response code: 200; Time: 18ms (18 ms); Content length: 7 bytes (7 B)
보면 굉장히 획기적인 기능 같은데 쓰지말자. 왜냐하면, 일단 이 코드를 이해하기가 정말 어렵다. 아니 분명 PathVariable로 ID를 받는데 갑자기 멤버로 받아? 싶기도 한데다가 가장 문제는 이 멤버는 절대적으로 조회용으로 밖에 사용할 수 없다. 왜냐하면 컨버터를 통해 멤버를 찾아오는 과정은 스프링 데이터 JPA 내부에서 해주는 작업이기 때문에 트랜잭션이 이 코드안에 없다. 따라서 쓰기 작업이 불가능하다. 즉, 영속성 컨텍스트가 이 컨트롤러 안에 없다는 의미다.
Web 확장 - 페이징과 정렬
스프링 데이터가 제공하는 페이징과 정렬 기능을 스프링 MVC에서 편리하게 사용할 수가 있다. 다음 코드를 보자.
@GetMapping("/members")
public Page<MemberDto> getMembers(Pageable pageable) {
return memberRepository.findAll(pageable).map(MemberDto::new);
}
JPA랑 Spring Data JPA랑 뭐가 다른건가요?에 대한 질문에 정확한 답변을 할 수 없다면 JPA와 스프링을 다시 공부해야 한다. JPA를 모르면 Spring Data JPA를 제대로 사용할 수 없다. JPA는 데이터 접근 기술이고 ORM이다. 지금은 스프링을 사용하는 개발자들에게는 거의 필수인 데이터 접근 기술인데 JPA를 사용하던, 다른 데이터 접근 기술을 사용하던 기본적인 CRUD 기능은 거의 대부분이 비슷하다. 심지어 이건 관계형 데이터베이스가 아닌 데이터베이스도 마찬가지로 기본적인 CRUD는 거의 대부분이 동일하다. 이렇게 유사한 기능을 가지고 있는데 기술이 가지각색인 경우 스프링은 항상 뭐다? 추상화를 한다.
그래서, 스프링 진영에서 데이터 접근 기술들이 이것 저것 많지만 기본적인 CRUD는 모두 동일하니 이거 추상화하자! 해서 만든 표준이 Spring Data라는 표준이고 그 표준을 특정 기술(여기서는 JPA)로 구현한 구현체 중 하나가 Spring Data JPA이다.
그럼 도대체 JPA가 있는데 뭐 얼마나 유사하다고 이 표준을 만든걸까? 한번 Spring Data JPA를 사용하지 않고 순수 JPA를 사용해서 레포지토리를 만들고 데이터 접근 기술을 사용해보자.
엔티티
Member
package cwchoiit.datajpa.entity;
import jakarta.persistence.*;
import lombok.*;
@Entity
@Getter
@Builder
@AllArgsConstructor
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@ToString(of = {"id", "username", "age"})
public class Member {
@Id
@GeneratedValue
@Column(name = "member_id")
private Long id;
private String username;
private int age;
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "team_id")
private Team team;
public Member(String username) {
this.username = username;
}
public void changeTeam(Team team) {
this.team = team;
team.getMembers().add(this);
}
}
Team
package cwchoiit.datajpa.entity;
import jakarta.persistence.*;
import lombok.*;
import java.util.ArrayList;
import java.util.List;
@Entity
@Getter
@Builder
@AllArgsConstructor
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@ToString(of = {"id", "name", "members"})
public class Team {
@Id
@GeneratedValue
@Column(name = "team_id")
private Long id;
private String name;
@OneToMany(mappedBy = "team", fetch = FetchType.LAZY)
@Builder.Default
private List<Member> members = new ArrayList<>();
}
간단하게 Member, Team 두 엔티티를 만들었다.
둘은 다대일 양방향 연관관계를 가지고 있고, 그렇기에 연관관계의 주인을 지정해야 한다. JPA 관련 포스팅에서 열심히 말했다. 연관관계의 주인은 항상 테이블 관점에서 외래키를 가지고 있는 쪽이 주인이 되면 된다고 했다. 고로 연관관계의 주인을 Member로 지정했다. 양방향 연관관계에서 연관관계의 주인이 아닌 Team은 mappedBy 속성으로 "나는 주인인 Member의 필드인 team에 매핑된 필드입니다."라고 알려주어야 한다.
지연로딩은 당연히 모두 다 걸어야 한다.
여기서 @ToString을 유심히 보면, Member에는 Team 필드를 제외한 것을 볼 수 있다. 왜 그러냐면, toString()을 호출할 때 팀까지 넣어버리면 팀을 호출하고, 팀은 멤버 리스트를 가지고 있기 때문에 멤버를 다시 호출한다. 그럼 팀이 멤버를 멤버는 팀을 계속해서 호출하는 문제가 발생해서 스택 오버플로우 에러를 마주하게 된다.
순수 JPA 레포지토리
MemberJpaRepository
package cwchoiit.datajpa.repository;
import cwchoiit.datajpa.entity.Member;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;
import java.util.List;
import java.util.Optional;
@Repository
@RequiredArgsConstructor
public class MemberJpaRepository {
private final EntityManager em;
public Member save(Member member) {
em.persist(member);
return member;
}
public Member find(Long id) {
return em.find(Member.class, id);
}
public Optional<Member> findById(Long id) {
Member member = em.find(Member.class, id);
return Optional.ofNullable(member);
}
public long count() {
return em.createQuery("SELECT COUNT(m) FROM Member m", Long.class)
.getSingleResult();
}
public List<Member> findAll() {
return em.createQuery("SELECT m FROM Member m", Member.class)
.getResultList();
}
public void delete(Member member) {
em.remove(member);
}
}
TeamJpaRepository
package cwchoiit.datajpa.repository;
import cwchoiit.datajpa.entity.Team;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;
import java.util.List;
import java.util.Optional;
@Repository
@RequiredArgsConstructor
public class TeamJpaRepository {
private final EntityManager em;
public Team save(Team team) {
em.persist(team);
return team;
}
public void delete(Team team) {
em.remove(team);
}
public List<Team> findAll() {
return em.createQuery("SELECT t FROM Team t", Team.class)
.getResultList();
}
public Optional<Team> findById(Long id) {
Team team = em.find(Team.class, id);
return Optional.ofNullable(team);
}
public long count() {
return em.createQuery("SELECT COUNT(t) FROM Team t", Long.class)
.getSingleResult();
}
}
직접 EntityManager를 주입받아서 순수한 JPA 레포지토리 코드를 작성한 모습이다. 코드만 봐도 알겠지만, Team과 Member가 참조하는 객체만 다를뿐 코드가 거의 100% 동일하다.
save(), delete(), findAll(), findById(), count() 모두 둘 다 가지고 있는 메서드이다.
@Repository 애노테이션을 달아서 이 클래스를 스프링 컨테이너를 띄울때 컴포넌트 스캔을 할 수 있도록 해줘야 한다. 참고로, @Repository를 달면 스프링은 데이터 접근 예외 추상화 기술도 넣어 프록시를 만든다. 그래서 어떤 데이터베이스를 사용하든지 예외가 발생하더라도 동일한 스프링 데이터 접근 예외가 발생한다.
이후에 Spring Data JPA를 사용하면 이 @Repository 애노테이션은 달 필요가 없다. 왜냐하면 JpaRepository를 상속받는 시점부터 이미 알아서 스프링 데이터 접근 예외 추상화도 해준다. 이건 이후에 직접 사용하면서 다시 보자.
순수하게 JPA 레포지토리를 작성하고 보니, 코드가 거의 동일하다. 엔티티가 10개면 10개의 레포지토리가 동일하게 가지는 이 기능들을 매번 구현해줘야 한다. 개발자는 게으르다. 이것을 참을 수 없다.
스프링 데이터 JPA 사용
스프링 데이터 JPA를 사용하기 위해선 다음 작업이 필요하다.
package cwchoiit.datajpa;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.data.jpa.repository.config.EnableJpaRepositories;
@SpringBootApplication
@EnableJpaRepositories(basePackages = "cwchoiit.datajpa.repository")
public class DataJpaApplication {
public static void main(String[] args) {
SpringApplication.run(DataJpaApplication.class, args);
}
}
엔트리 지점인 메인 클래스에 @EnableJpaRepositories 애노테이션을 달아서 어떤 패키지에 스프링 데이터 JPA 레포지토리를 가지고 있는지 알려줘야 한다. 그래야 그 지점에 가서 레포지토리들을 컴포넌트 스캔으로 빈 등록하기 때문이다.
그런데, 스프링 부트를 사용하는 우리는 이게 필요없다. 스프링 부트가 자동으로 컴포넌트 스캔을 해주는데 어디서부터 해주냐? 바로 이 클래스(DataJpaApplication)가 존재하는 패키지 하위부터 모든 패키지를 다 뒤져서 찾는다.
그래서 다시 제거한 모습으로 놔두자!
package cwchoiit.datajpa;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class DataJpaApplication {
public static void main(String[] args) {
SpringApplication.run(DataJpaApplication.class, args);
}
}
스프링 데이터 JPA 공통 인터페이스
이제, 스프링 데이터 JPA가 제공하는 인터페이스를 상속받는 인터페이스를 만들기만 하면 끝이다.
위에서 만든 MemberRepository를 주입받아서 이 클래스 정보를 찍어보면 다음과 같이 나온다.
실행 결과
2024-12-12T14:18:13.905+09:00 INFO 15409 --- [ Test worker] c.d.repository.MemberRepositoryTest : memberRepository class = class jdk.proxy3.$Proxy125
JDK 동적 프록시를 사용해서 프록시로 만든 모습을 확인할 수 있다.
스프링 데이터 JPA 사용하여 테스트하기
MemberRepositoryTest
package cwchoiit.datajpa.repository;
import cwchoiit.datajpa.entity.Member;
import cwchoiit.datajpa.repository.springdatajpa.MemberRepository;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.transaction.annotation.Transactional;
import java.util.List;
import static org.assertj.core.api.Assertions.assertThat;
@Slf4j
@SpringBootTest
@Transactional
class MemberRepositoryTest {
@Autowired
MemberRepository memberRepository;
@Test
void crud() {
Member member1 = Member.builder()
.username("member1")
.build();
Member member2 = Member.builder()
.username("member2")
.build();
memberRepository.save(member1);
memberRepository.save(member2);
Member findMember1 = memberRepository.findById(member1.getId()).orElseThrow();
Member findMember2 = memberRepository.findById(member2.getId()).orElseThrow();
assertThat(findMember1).isEqualTo(member1);
assertThat(findMember2).isEqualTo(member2);
List<Member> members = memberRepository.findAll();
assertThat(members.size()).isEqualTo(2);
long memberCount = memberRepository.count();
assertThat(memberCount).isEqualTo(2);
memberRepository.delete(member1);
memberRepository.delete(member2);
long afterRemovedCount = memberRepository.count();
assertThat(afterRemovedCount).isEqualTo(0);
}
}
이런 코드를 작성했다. 어? 나는 findAll(), count(), delete(), findById(), save() 만든 적이 없는데 잘 작성이 된다. 당연히 되지! 스프링 데이터 JPA가 구현체를 다 만들어 놨으니까!
실행 결과
스프링 데이터 JPA 공통 인터페이스 분석
그럼 스프링 데이터 JPA 공통 인터페이스인 JpaRepository가 어떻게 생긴걸까?
이런 모양으로 생겼다. 참고로, Deprecated 된 메서드도 있다. getOne()이 대표적이다. 그리고 findOne()은 findById()로 변경되었다. 메서드 명이나 이런게 중요한게 아니고 여기서 핵심은 이런 구조를 가지고 있다는 점이다.
맨 위에서 스프링이 데이터 접근 기술을 추상화했고 그게 Spring Data라고 했다. 그리고 그 여러 데이터 접근 기술 중 하나인 JPA를 가지고 구현한 구현체가 Spring Data JPA일 뿐이다.
그래서 이거 타고 올라가보면, JpaRepository는 패키지 명이 다음과 같다.
보다시피, org.springframework.data.jpa.repository이다.
이 위로 올라가서 PagingAndSortingRepository 올라가보면 패키지 명이 다음과 같다.
보다시피 org.springframework.data.repository이다.
이 말은, 스프링 데이터 JPA보다 위에있는 것들은 JPA뿐 아니라 Spring Data를 구현한 구현체들은 모두 가지고 있는 기능들이란 뜻이다. 그래서 위에서 말한대로 어떤 데이터베이스를 사용하든지 공통 기능을 추상화했다고 말한것이다.
스프링 데이터 JPA가 제공하는 공통 CRUD 말고는요?
그럼, save(), delete(), findAll() 등 공통적으로 어떤 데이터베이스든 필요한 메서드는 편리하게 사용할 수 있다는 것을 알았다. 근데 당연히 비즈니스적으로 프로젝트마다 엔티티도 다를 것이다. 예를 들면 어떤 프로젝트는 Member라는 엔티티가 있는가 하면 User라는 엔티티를 가진 프로젝트도 있을 것이다. 이런것까지 스프링 데이터 JPA가 다 만들어주진 않는다. 그럼 뭐 마냥 좋은게 아니네? 라고 생각이 들 수 있는데 이 스프링 데이터 JPA가 또 마법같은 일을 부린다.
바로, 메서드 시그니처만으로 어떤 쿼리를 사용할지를 유추해서 그냥 해당 메서드 쿼리를 만들어버린다! 예를 들면 다음과 같이 코드를 작성하자.
트랜잭션을 사용하려면, 먼저 스프링 빈에 등록된 어떤 트랜잭션 매니저를 사용할지 알아야 한다. @Transactional 애노테이션도 결국 트랜잭션 매니저를 사용하는거기 때문에 트랜잭션 매니저를 지정해줘야 하고 지정할 때는 value, transactionManager 둘 중 하나에 트랜잭션 매니저의 스프링 빈의 이름을 적어주면 된다. 지정하지 않으면 기본으로 등록된 트랜잭션 매니저를 사용하기 때문에 대부분 생략한다. 그러나 트랜잭션 매니저가 둘 이상이면 다음처럼 트랜잭션 매니저의 이름을 지정해서 구분하면 된다.
@Transactional("memberTxManager")
public void member() {...}
@Transactional("orderTxManager")
public void order() {...}
참고로, 애노테이션에서 속성이 하나인 경우 위 예처럼 value는 생략하고 값을 바로 넣을 수 있다.
rollbackFor
트랜잭션 내 로직을 수행 중 예외가 발생하면 스프링 트랜잭션의 기본 정책은 다음과 같다.
언체크 예외(런타임 예외라고도 함)인 RuntimeException, Error 또는 그 하위 예외가 발생하면 롤백
체크 예외인 Exception 또는 그 하위 예외들은 커밋
이 옵션을 사용해서 기본 정책에 '추가적으로' 어떤 예외가 발생했을 때 롤백을 하라고 지정할 수 있다.
@Transactional(rollbackFor = Exception.class)
이렇게 하면 Exception부터 그 하위 예외들이 발생해도 롤백한다.
rollbackForClassName이라는 속성도 있는데 이는 문자로 넣는 경우이다. 그냥 rollbackFor를 사용하면 된다.
noRollbackFor
이는 rollbackFor와 반대 개념이다. 기본 정책에 추가로 어떤 예외가 발생하면 롤백하면 안되는지 지정할 수 있다. 마찬가지로 noRollbackForClassName도 있다.
propagation
이는 트랜잭션 전파에 대한 내용이다. 매우 중요하다.우선 가능 옵션 리스트는 다음과 같다.
전파타입
설명
REQUIRED ⭐️
기본값으로 설정되는 전파 타입입니다. 기존에 활성화된 트랜잭션에 자식 트랜잭션이 합류하여 하나의 물리 트랜잭션으로 취급합니다. 기존 트랜잭션이 없다면 새로 트랜잭션을 만듭니다.
REQUIRES_NEW ⭐️
기존에 활성화된 트랜잭션이 있더라도 합류하지 않고 별개의 트랜잭션으로 취급하여 수행되는 전파 타입입니다.
SUPPORTS
기존에 활성화된 트랜잭션이 있다면 합류를 하고, 활성화된 트랜잭션이 없다면 합류하지 않고 트랜잭션 없이 그대로 작업을 수행합니다. 트랜잭션이 그다지 필요없는 SELECT 쿼리에 적용하면 성능 향상을 기대할 수 있다고도 합니다.
NOT_SUPPORTED
트랜잭션을 지원하지 않는다는 의미입니다. 그래서, 기존 트랜잭션이 없으면 트랜잭션이 없이 진행하고, 기존 트랜잭션이 있어도 트랜잭션이 없이 진행합니다.
MANDATORY
기존에 활성화된 트랜잭션이 존재할 경우 해당 트랜잭션에 합류하며, 존재하지 않을 경우 예외를 발생시킵니다. 쉽게 말해 기존 트랜잭션이 반드시 있어야 합니다.
NEVER
기존에 활성화된 트랜잭션이 존재할 경우 예외를 발생시키며, 활성화된 트랜잭션이 없을 경우 작업을 수행합니다.
NESTED
기존 트랜잭션이 없으면 새로운 트랜잭션을 만들고 기존 트랜잭션이 있으면 중첩 트랜잭션을 만듭니다. 중첩 트랜잭션은 외부(기존) 트랜잭션에 영향을 받지만, 중첩 트랜잭션은 외부 트랜잭션에 영향을 주지 않습니다. 즉, 중첩 트랜잭션이 롤백 되어도 외부 트랜잭션은 커밋할 수 있지만 외부 트랜잭션이 롤백되면 중첩 트랜잭션도 같이 롤백됩니다. (중첩 트랜잭션은 JPA에서는 사용할 수 없는 옵션입니다)
참고로, 트랜잭션 옵션 중 isolation, timeout, readOnly는 트랜잭션이 처음 시작될 때만 적용된다. 즉, 트랜잭션에 참여하는 경우에는 적용되지 않는다. 예를 들어, REQUIRED를 통한 트랜잭션 시작이나 REQUIRES_NEW를 통한 트랜잭션 시작 시점에만 적용되고 트랜잭션에 참여하는 트랜잭션은 기존 트랜잭션을 시작할 때 적용했던 옵션을 따라 사용된다.
propagation - REQUIRED
기본값은 REQUIRED인데, 이 옵션은 위에 설명한 그대로 기존에 활성화된 트랜잭션이 있으면 그 트랜잭션에 합류한다. 좀 더 정확히 말하면 '물리 트랜잭션'과 '논리 트랜잭션'으로 나뉘어지는데 다음 그림을 보자.
1. 클라이언트에서 트랜잭션을 가지는 서비스를 호출하면 트랜잭션이 시작된다.
2. 하나의 트랜잭션에서 실행되던 로직에서 새로운 트랜잭션을 가지는 또다른 서비스를 호출하여 트랜잭션 두개가 생성된다.
3. 이 두개의 트랜잭션은 논리 트랜잭션으로 나뉘어지고 이 두개의 논리 트랜잭션을 크게 묶어 하나의 물리 트랜잭션으로 합류된다.
이런 흐름이 REQUIRED 옵션이다. 이렇게 하나의 물리 트랜잭션으로 합류가 된다. 그리고 이 물리 트랜잭션이 실제 데이터베이스와 통신하는 트랜잭션이고 논리 트랜잭션들은 애플리케이션 레벨에서 트랜잭션을 시작하고 종료(커밋 또는 롤백)하는 트랜잭션이다.
이 경우, 중요한 두가지 규칙이 있다.
두 개의 논리 트랜잭션이 모두 커밋되어야 물리 트랜잭션이 커밋된다.
두 개의 논리 트랜잭션 중 하나라도 롤백이라면 물리 트랜잭션은 롤백된다.
다음 그림을 보고 이와 같이 정하자.
최초 시작되는 트랜잭션을 외부 트랜잭션, 내부 로직에서 또다른 트랜잭션을 만들려 하는 곳을 내부 트랜잭션이라고 칭하자.
둘 다 논리 트랜잭션이고 이 두개의 논리 트랜잭션이 모두 커밋되어야 하나의 물리 트랜잭션(실제 데이터베이스에 커밋 또는 롤백을 날리는)이 커밋된다고 했다. 실제로 코드를 통해서 어떻게 동작하는지 눈으로 직접 확인해보자!
외부 트랜잭션(outer)를 시작한다. 최초로 트랜잭션이 수행되면 신규 트랜잭션이 되고 그 값을 보관하고 있기 때문에 outer.isNewTransaction()을 호출하면 `true`를 반환한다.
외부 트랜잭션이 수행중인데 내부 트랜잭션(inner)을 추가로 수행했다. 내부 트랜잭션을 시작하는 시점에는 이미 외부 트랜잭션이 진행중인 상태이다. 이 경우 내부 트랜잭션은 외부 트랜잭션에 참여한다.
내부 트랜잭션이 외부 트랜잭션에 참여한다는 뜻은 내부 트랜잭션이 외부 트랜잭션을 그대로 이어 받아서 따른다는 뜻이다. 다른 관점으로 보면 외부 트랜잭션의 범위가 내부 트랜잭션까지 넓어진다는 뜻이다.
내부 트랜잭션은 이미 진행중인 외부 트랜잭션에 참여하므로 신규 트랜잭션이 아니다. 그러므로 inner.isNewTransaction()을 호출하면 `false`가 된다.
내부 트랜잭션을 커밋한 후 외부 트랜잭션도 커밋했다. (당연히 내부 트랜잭션을 먼저 커밋하고 외부 트랜잭션이 커밋되는게 순서가 맞다)
실행 결과
2024-12-11T16:15:04.484+09:00 INFO 75930 --- [ Test worker] cwchoiit.tx.propagation.BasicTxTest : 외부 트랜잭션 시작
2024-12-11T16:15:04.485+09:00 DEBUG 75930 --- [ Test worker] o.s.j.d.DataSourceTransactionManager : Creating new transaction with name [null]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT
2024-12-11T16:15:04.486+09:00 DEBUG 75930 --- [ Test worker] o.s.j.d.DataSourceTransactionManager : Acquired Connection [HikariProxyConnection@-397934204 wrapping conn0: url=jdbc:h2:mem:3b843fdd-51b1-4753-80e2-eff01972f785 user=SA] for JDBC transaction
2024-12-11T16:15:04.487+09:00 DEBUG 75930 --- [ Test worker] o.s.j.d.DataSourceTransactionManager : Switching JDBC Connection [HikariProxyConnection@-397934204 wrapping conn0: url=jdbc:h2:mem:3b843fdd-51b1-4753-80e2-eff01972f785 user=SA] to manual commit
2024-12-11T16:15:04.487+09:00 INFO 75930 --- [ Test worker] cwchoiit.tx.propagation.BasicTxTest : outer.isNewTransaction() = true
2024-12-11T16:15:04.487+09:00 INFO 75930 --- [ Test worker] cwchoiit.tx.propagation.BasicTxTest : 내부 트랜잭션 시작
2024-12-11T16:15:04.487+09:00 DEBUG 75930 --- [ Test worker] o.s.j.d.DataSourceTransactionManager : Participating in existing transaction
2024-12-11T16:15:04.487+09:00 INFO 75930 --- [ Test worker] cwchoiit.tx.propagation.BasicTxTest : inner.isNewTransaction() = false
2024-12-11T16:15:04.487+09:00 INFO 75930 --- [ Test worker] cwchoiit.tx.propagation.BasicTxTest : 내부 트랜잭션 커밋
2024-12-11T16:15:04.487+09:00 INFO 75930 --- [ Test worker] cwchoiit.tx.propagation.BasicTxTest : 외부 트랜잭션 커밋
2024-12-11T16:15:04.487+09:00 DEBUG 75930 --- [ Test worker] o.s.j.d.DataSourceTransactionManager : Initiating transaction commit
2024-12-11T16:15:04.488+09:00 DEBUG 75930 --- [ Test worker] o.s.j.d.DataSourceTransactionManager : Committing JDBC transaction on Connection [HikariProxyConnection@-397934204 wrapping conn0: url=jdbc:h2:mem:3b843fdd-51b1-4753-80e2-eff01972f785 user=SA]
2024-12-11T16:15:04.488+09:00 DEBUG 75930 --- [ Test worker] o.s.j.d.DataSourceTransactionManager : Releasing JDBC Connection [HikariProxyConnection@-397934204 wrapping conn0: url=jdbc:h2:mem:3b843fdd-51b1-4753-80e2-eff01972f785 user=SA] after transaction
로그를 보면 꽤나 흥미로운데, 내부 트랜잭션을 시작할 때 `Participating in existing transaction` 이라는 메시지를 확인할 수 있다. 이 메시지는 내부 트랜잭션이 기존에 존재하는 외부 트랜잭션에 참여한다는 뜻이다. 근데 어떻게 알까? 아까 위에서 말한 신규 트랜잭션인지를 확인해서 신규 트랜잭션이 아닌 경우에 전파 속성의 기본값인 기존 트랜잭션에 참여하는 방식을 사용하기 때문이다.
그리고 내부 트랜잭션을 커밋하고 나서 커밋 로그가 전혀 찍혀있지 않다. 그리고 외부 트랜잭션을 커밋한다는 로그가 나오고 나서 커밋 로그가 찍혀있다. 왜 그럴까? 트랜잭션을 커밋하는 순간 그 트랜잭션은 더이상 사용할 수 없다. 아예 끝난다. 그런데 외부 트랜잭션이 남아있는데 내부 트랜잭션을 커밋한다고 해서 물리 트랜잭션을 커밋해버리면 외부 트랜잭션에서는 작업했던 내용을 반영할 수 없기 때문이다.
그래서 스프링은 이렇게 여러 트랜잭션이 함께 사용되는 경우, 처음 트랜잭션을 시작한 외부 트랜잭션이 실제 물리 트랜잭션을 관리하도록 한다. 따라서 외부 트랜잭션이 커밋되어야만 실제 물리 트랜잭션을 커밋한다는 로그가 찍히는 것이다.
그래서 내부 트랜잭션이 정상적으로 커밋이 되고, 외부 트랜잭션도 커밋이 되어야만 커밋을 한다는 로그가 찍히는 모습이다.
여기서 그럼, 둘 중 하나가 롤백을 한다면 결국 물리 트랜잭션이 롤백이 되는데 이 때 외부 트랜잭션과 내부 트랜잭션이 롤백을 할 때 처리되는 방식이 다르다. 이것을 이해해야 한다.
외부 트랜잭션이 최초의 트랜잭션이기 때문에 결국 이 외부 트랜잭션이 커밋 또는 롤백을 해야 물리 트랜잭션이 커밋 또는 롤백을 한다.
내부 트랜잭션은 커밋이나 롤백을 해도 물리 트랜잭션은 아무런 작업을 하지 않는다. 왜냐? 외부 트랜잭션이 아직 남아있기 때문에.
1.내부 트랜잭션이 커밋되고 외부 트랜잭션이 롤백이 되면 그냥 롤백 처리가 된다. 2.내부 트랜잭션이 롤백되고 외부 트랜잭션이 커밋되면 UnexpectedRollbackException 예외가 터진다.
저 부분이 중요하다. 내부 트랜잭션이 롤백을 하면 물리 트랜잭션이 롤백을 바로 하지 않지만(물리 트랜잭션이 롤백 또는 커밋이 되면 데이터베이스에 실제 커밋 또는 롤백을 날리는데 아직 트랜잭션이 끝난게 아니니까) 물리 트랜잭션에 Rollback-Only 라는 마크를 달게 된다.
여기서 외부 트랜잭션이 커밋이 된다면 물리 트랜잭션에 커밋을 날리는데 커밋을 할 수 없는것이다. 왜냐? 내부 트랜잭션이 롤백을 했으니까. 그러나 개발자는 외부 트랜잭션을 커밋을 했는데 커밋이 되면 안되니까 UnexpectedRollbackException이 발생하는 것이다. 즉, 스프링 입장에서는 "너가 지금 물리 트랜잭션을 커밋하려고 시도했지만 내부 트랜잭션에서 롤백을 날렸기 때문에 넌 커밋을 할 수 없어"라고 친절하게 알려주는 것. 이것을 코드로 한번 봐보자!
이 경우에 전체 트랜잭션인 물리 트랜잭션은 롤백을 하고 UnexpectedRollbackException 예외를 던진다.
실행 결과
실행 결과를 보면 UnexpectedRollbackException이 발생했음을 알 수 있다.
그리고, 내부 트랜잭션을 롤백할 때 찍히는 로그를 보면 `marking existing transaction as rollback-only` 라는 로그가 찍혀있다. 내부 트랜잭션은 물리 트랜잭션에 커밋이나 롤백을 할 수 없기 때문에 현재 이 물리 트랜잭션에 나 롤백했어! 라고 마킹을 하는 것이다. 그래야 외부 트랜잭션에서 커밋이든 롤백이든 뭔가 하려고 할 때 확인하고 롤백을 할 수 있을테니 말이다.
이게 기본 전파 속성 'REQUIRED'의 동작 흐름이다.
그래서 진짜 진짜 중요하게 이해해야 하는 부분이 있는데, 아래 그림을 보자.
위 그림처럼 트랜잭션에서 또 다른 트랜잭션을 가지는 내부 로직이 있고 이 세 개의 트랜잭션이 모두 REQUIRED 전파 타입인 경우가 있다고 가정하자.
REQUIRED 전파 속성은 모두 커밋이 되어야 물리 트랜잭션이 커밋되고 하나라도 롤백이라면 물리 트랜잭션은 롤백된다고 했다.
근데 만약, 런타임 예외가 발생한 지점에서 예외 처리를 하지 못하고 자신을 호출한 곳으로 예외를 던졌다고 가정하자. 당연히 이 로직의 트랜잭션은 롤백을 할 것이다. 그러나 이 트랜잭션이 가장 최초에 시작된 트랜잭션이 아니라면 롤백을 바로 데이터베이스에 날리는 게 아니라 Rollback Only 마킹을 하고 끝나는데, 그럼 이 예외를 넘겨받은 바깥쪽 트랜잭션 로직에서 이 예외를 복구했다면? 즉 예외를 잡아서 처리했다면? 이 전체 물리 트랜잭션은 커밋이 성공적으로 될까? 아니다. 그렇지 않다. 왜냐하면 결국 이 REQUIRED 전파 타입은 사용중인 트랜잭션에 참여하기 때문에 내부의 논리 트랜잭션에서 하나라도 rollback only에 마킹을 했다면 무조건 물리 트랜잭션은 롤백을 한다. 근데 예외를 잡아버리니까 정상 흐름을 유지하고 트랜잭션을 커밋을 할 거라고 기대하는 경우가 종종 있을 수 있다. 충분히 그럴수 있다는 생각이든다. 하지만 아니라는 것을 꼭 염두하자.
코드를 통해서 직접 확인해보자!
MemberService
package cwchoiit.tx.propagation;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;
@Slf4j
@Service
@RequiredArgsConstructor
public class MemberService {
private final MemberRepository memberRepository;
private final LogRepository logRepository;
@Transactional
public void joinV1(String username) {
Member member = new Member(username);
Log logEntity = new Log(username);
log.info("MemberRepository 호출 시작");
memberRepository.save(member);
log.info("MemberRepository 호출 종료");
log.info("LogRepository 호출 시작");
logRepository.save(logEntity);
log.info("LogRepository 호출 종료");
}
@Transactional
public void joinV2(String username) {
Member member = new Member(username);
Log logEntity = new Log(username);
log.info("MemberRepository 호출 시작");
memberRepository.save(member);
log.info("MemberRepository 호출 종료");
log.info("LogRepository 호출 시작");
try {
logRepository.save(logEntity);
} catch (RuntimeException e) {
log.info("로그 저장에 실패했습니다. logMessage = {}", logEntity.getMessage());
}
log.info("LogRepository 호출 종료");
}
}
간단한 Member 관련 서비스 코드이다. joinV1, joinV2 메서드가 있다.
각 메서드에 @Transactional 애노테이션을 달았고, 아무런 옵션도 주지 않았으니 전파 옵션은 기본값인 REQUIRED이다.
MemberRepository
package cwchoiit.tx.propagation;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Repository;
import org.springframework.transaction.annotation.Transactional;
import java.util.Optional;
@Slf4j
@Repository
@RequiredArgsConstructor
public class MemberRepository {
private final EntityManager em;
@Transactional
public void save(Member member) {
log.info("Saving member {}", member);
em.persist(member);
}
public Optional<Member> findById(String username) {
return em.createQuery("SELECT m FROM Member m WHERE m.username = :username", Member.class)
.setParameter("username", username)
.getResultList()
.stream()
.findFirst();
}
}
MemberRepository에서 save() 메서드를 보면 이 메서드에도 @Transactional 애노테이션이 달려있다.
LogRepository
package cwchoiit.tx.propagation;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Repository;
import org.springframework.transaction.annotation.Transactional;
import java.util.Optional;
@Slf4j
@Repository
@RequiredArgsConstructor
public class LogRepository {
private final EntityManager em;
@Transactional
public void save(Log logMessage) {
log.info("log 저장");
em.persist(logMessage);
if (logMessage.getMessage().contains("로그예외")) {
log.info("Log 저장 시 예외 발생");
throw new RuntimeException("예외 발생");
}
}
public Optional<Log> find(String message) {
return em.createQuery("SELECT l FROM Log l WHERE l.message = :message", Log.class)
.setParameter("message", message)
.getResultList()
.stream()
.findFirst();
}
}
이런 상태에서 MemberService.joinV1(), joinV2()를 호출하면, MemberRepository.save()도 호출하고, LogRepository.save()도 호출한다. 그리고 joinV1, joinV2에 @Transactional이 붙어있기 때문에 트랜잭션을 최초로 시작하는 지점은 이 곳이고, MemberRepository.save()와 LogRepository.save()에 붙어있는 @Transactional은 전파 옵션이 REQUIRED이므로 기존 트랜잭션에 참여한다.
즉, 외부 트랜잭션, 내부 트랜잭션, 내부 트랜잭션 이렇게 총 세개의 논리 트랜잭션이 있게 되고, 모두가 커밋해야 물리 트랜잭션이 커밋이 되고 하나라도 롤백이면 물리 트랜잭션은 롤백이다. 이게 REQUIRED 옵션이니까. 그런데 이 코드는 사용자가 회원가입을 할때 호출되는 코드인데 회원가입 시 비즈니스 규칙으로 Log라는 엔티티에 해당 유저를 저장하는 부가 기능이 있을뿐이다. LogRepository.save()에서 어떤 예외가 발생했다고 해서 사용자 회원가입까지 못시키게 해버리면 사용자 입장에서는 원인도 모르고 그냥 회원가입이 안되는 상황을 마주하게 된다. 그게 싫어서 MemberService.joinV2()에서 LogRepository.save()의 예외가 올라오면 그 예외를 잡아버린다고 코드를 작성한 것이다. 이런다고 롤백이 안되는게 아니다! 이미 LogRepository.save()에서 실행된 논리 트랜잭션은 Rollback-only마크를 찍었다. 그럼 외부 트랜잭션에서 정상흐름으로 커밋을 하더라도 절대 물리 트랜잭션은 커밋되지 않는다. 테스트 코드로 테스트를 해보자.
/**
* memberService @Transactional: ON
* memberRepository @Transactional: ON
* logRepository @Transactional: ON Exception
*/
@Test
void recover_exception_fail() {
String username = "로그예외_recover_exception_fail";
assertThatThrownBy(() -> memberService.joinV2(username)).isInstanceOf(UnexpectedRollbackException.class);
assertThat(memberRepository.findById(username)).isEmpty();
assertThat(logRepository.find(username)).isEmpty();
}
joinV2를 호출하는데 이 메서드는 분명히 UnexpectedRollbackException을 던질 것이다.
그리고 데이터베이스에 Log 엔티티 뿐 아니라, Member 엔티티 역시 저장되지 않았을 것이다. 물리 트랜잭션은 롤백이 되기 때문에.
실행 결과
실행 결과를 보면 테스트는 통과하고 로그는 커밋을 시도했는데 트랜잭션에 rollback-only 마크가 찍혀있기 때문에 롤백을 한다라는 로그가 뚜렷히 보인다. 이 경우, 어떻게 해결할 수 있을까? 가장 간단한 건 바로 다음에 소개할 REQUIRES_NEW 전파 옵션을 사용하면 된다.
또다른 방법으로는 MemberRepository.save(), LogRepository.save() 이 두 개가 각각의 트랜잭션을 사용하면 된다. 아 물론 REQUIRES_NEW도 각각의 트랜잭션인데 MemberRepository.save()는 기존 트랜잭션에 참여하는 상태이고(왜냐하면, MemberService.joinV2()가 @Transactional이 있기 때문에 여기가 최초의 트랜잭션 시작점이라 그렇다) LogRepository.save()는 새로운 트랜잭션을 열어버리는게 REQUIRES_NEW인데, 아예 각각의 트랜잭션이 둘 다 물리 트랜잭션이 되게끔 MemberService.joinV2()에 있는 @Transactional을 없애버리면, 각각 트랜잭션이 둘 다 물리 트랜잭션이 되는 그런 경우로도 해결할 수 있다.
근데 이 방법의 문제는, 트랜잭션의 가장 중요한 특성인 원자성을 해친다는 점이다. 결국은 멤버를 저장하고, 로그를 저장하는 작업은 MemberService.joinV2()안에서 모두 일어나는 건데 이 joinV2()가 트랜잭션을 시작해야 이 안에서 일어난 모든 작업이 성공하거나 모든 작업이 실패하게 할 수 있다. 그런데 여기에 트랜잭션을 거는게 아니라, 각각의 save() 메서드에 걸어버리면 어떤건 성공하고 어떤건 실패하는 경우가 되는 것이다. 이게 만약 출금과 입금 작업이라면 큰 문제가 된다. 그러나 지금같은 비즈니스 규칙이 생겨서 로그를 저장하는데 실패하더라도 멤버는 회원가입 시키게 하고 싶다라는 룰이 프로젝트에 만들어졌으면 이런 방식으로도 해결을 할 수 있다는 말이다. 그래서 정답이 딱 있는게 아니라는 말을 하고 싶었다.
propagation -REQUIRES_NEW
REQUIRES_NEW는 위에서 설명한 REQUIRED와 다르게 새 트랜잭션을 사용하는 내부 로직이 있으면, 이전 트랜잭션과 완전히 분리된 새로운 트랜잭션에서 동작하는 방식이다. 즉, 또다른 커넥션이 사용된다.
기존 트랜잭션(A)이 있는 경우 해당 트랜잭션을 잠시 보류한 뒤 새로운 트랜잭션(B)을 만들어서 그 트랜잭션(B)을 사용하고 내부 로직이 모두 종료되는 시점에 트랜잭션(B)을 커밋 또는 롤백한 후 기존 트랜잭션(A)이 다시 사용된다.
그림으로 보면 다음으로 이해할 수 있다.
즉, 완전히 분리된 물리 트랜잭션을 가지며 어느 한쪽이 다른 한쪽에게 영향을 주지 않는다. 다시 말해 기존 물리 트랜잭션이 커밋이나 롤백을 하던, 새로운 물리 트랜잭션이 커밋이나 롤백을 하던 아무런 영향을 서로에게 주지 않는다. 자기 할 것을 한다. 이것도 코드로 한번 봐보자.
내부 트랜잭션(inner)을 시작할 때 전파 옵션인 propagationBehavior에 PROPAGATION_REQUIRES_NEW 옵션을 주었다.
이렇게 하면 내부 트랜잭션을 시작할 때 기존 트랜잭션에 참여하는 게 아니라 새로운 물리 트랜잭션을 만들어서 시작하게 된다.
당연히, 각각의 커밋과 롤백이 따로 수행된다.
실행 결과
실행 결과를 보면 외부 트랜잭션, 내부 트랜잭션의 각각 커넥션이 conn0, conn1로 다른 것을 알 수 있고, 내부 트랜잭션을 롤백할때 바로 트랜잭션 롤백 로그가 남는 것을 확인할 수 있다.
외부 트랜잭션을 커밋할때도 커밋 로그가 따로 남는 것을 확인할 수 있다.
주의
REQUIRES_NEW를 사용할 때 주의할 점은 커넥션이 쉽게 고갈될 수 있다. 만약 고객이 10명 접속했다고 하면 이 전파 옵션을 사용할 경우 쉽게 말해 20개의 커넥션을 사용할 수 있다. 내부 트랜잭션을 모두 이 옵션으로 사용한 경우에 해당하는 말이지만. 그래서, 이 옵션은 주의하면서 사용해야 한다.
문제 해결
아까 위에서 겪었던 MemberService, MemberRepository, LogRepository 이 문제를 REQUIRES_NEW로 해결해보자! 건드릴 부분은 딱 한 부분이다. LogRepository의 save() 메서드에 붙어있는 @Transactional에 전파 옵션을 REQUIRES_NEW로 변경만 해주면 된다. 아래 코드를 보자.
package cwchoiit.tx.propagation;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Repository;
import org.springframework.transaction.annotation.Propagation;
import org.springframework.transaction.annotation.Transactional;
import java.util.Optional;
@Slf4j
@Repository
@RequiredArgsConstructor
public class LogRepository {
private final EntityManager em;
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void save(Log logMessage) {
log.info("log 저장");
em.persist(logMessage);
if (logMessage.getMessage().contains("로그예외")) {
log.info("Log 저장 시 예외 발생");
throw new RuntimeException("예외 발생");
}
}
...
}
@Transactional(propagation = Propagation.REQUIRES_NEW)를 사용하므로써, 이 메서드가 호출되면 아예 새로운 커넥션을 만든다. 즉, MemberService.joinV2()에서 만든 커넥션과는 별개의 커넥션으로 동작하므로, 이 LogRepository.save()에서 롤백을 하더라도 MemberService.joinV2()에는 아무런 영향을 끼치지 않는다.
테스트 코드로 실행해보자.
/**
* memberService @Transactional: ON
* memberRepository @Transactional: ON
* logRepository @Transactional: ON (REQUIRES_NEW)
*/
@Test
void recover_exception_success() {
String username = "로그예외_recover_exception_success";
memberService.joinV2(username);
assertThat(memberRepository.findById(username)).isNotNull();
assertThat(logRepository.find(username)).isEmpty();
}
joinV2()는 이제 어떠한 에러도 던지지 않을 것이다. 별개의 트랜잭션을 사용하기 때문에 LogRepository.save()가 롤백을 하더라도 아무런 영향을 받지 않는다.
그렇게 되면, 멤버는 잘 저장이 되고 로그는 남지 않은 그런 상태가 된다.
실행 결과
isolation
트랜잭션 격리 수준을 지정할 수 있다. 기본값은 데이터베이스에서 설정한 트랜잭션 격리 수준을 사용하는 'DEFAULT'이다. 대부분 데이터베이스에서 설정한 기준을 따른다. 애플리케이션 개발자가 트랜잭션 격리 수준을 직접 지정하는 경우는 드물다.
DEFAULT: 데이터베이스에서 설정한 격리 수준을 따른다.
READ_UNCOMMITTED: 커밋되지 않은 읽기 (특정 레코드를 변경 후 커밋하지 않았을 시점에서도 변경된 값을 적용해서 데이터베이스를 통해 읽어올 수 있음을 의미)
READ_COMMITED: 커밋된 읽기 (특정 레코드를 변경 후 커밋하지 않으면 변경된 값이 아닌 직전 커밋 데이터를 읽음)
REPEATABLE_READ: 반복 가능한 읽기
SERIALIZABLE: 직렬화 가능
timeout
트랜잭션 수행 시간에 대한 타임아웃을 초 단위로 지정. 기본값은 트랜잭션 시스템의 타임아웃을 사용한다. 운영 환경에 따라 동작하는 경우도 있고 그렇지 않은 경우도 있기 때문에 꼭 확인하고 사용해야 한다.
label
트랜잭션 애노테이션에 있는 값을 직접 읽어서 어떤 동작을 하고 싶을 때 사용할 수 있다. 일반적으로 사용하지 않는다.
readOnly
트랜잭션은 기본적으로 읽기 쓰기가 모두 가능한 트랜잭션이 생성된다. `readOnly=true` 옵션을 사용하면 읽기 전용 트랜잭션이 생성된다. 이 경우 등록, 수정, 삭제가 안되고 읽기 기능만 동작한다. (드라이버나 데이터베이스에 따라 정상 동작하지 않는 경우도 있다) 그리고 이 옵션을 사용하면 읽기에서 다양한 성능 최적화가 발생할 수 있다.
readOnly 옵션은 크게 3가지에 적용된다.
프레임워크
JdbcTemplate은 읽기 전용 트랜잭션 안에서 변경 기능을 실행하면 예외를 던진다.
JPA는 읽기 전용 트랜잭션의 경우 커밋 시점에 `flush()`를 호출하지 않는다. 읽기 전용이니 변경에 사용되는 플러시를 호출할 필요가 없다. 추가로 변경이 필요 없으니 변경 감지를 위한 스냅샷 객체도 생성하지 않는다. 이렇게 JPA에서는 다양한 최적화가 발생
JDBC 드라이버 (DB와 드라이버 버전에 따라 다르게 동작하기 때문에 사전 확인 필요)
읽기 전용 트랜잭션에서 변경 쿼리가 발생하면 예외를 던진다.
읽기, 쓰기 데이터베이스를 구분해서 요청한다. 읽기 전용 트랜잭션의 경우 읽기 데이터베이스의 커넥션을 획득해서 사용한다. 읽기 전용 트랜잭션의 경우 읽기 데이터베이스의 커넥션을 획득해서 사용한다.
데이터베이스
데이터베이스에 따라 읽기 전용 트랜잭션의 경우 읽기만 하면 되므로, 내부에서 성능 최적화가 발생한다.
체크 예외 / 언체크 예외(런타임 예외) 발생 시 커밋 또는 롤백
위 속성을 설명하면서 스프링 트랜잭션의 기본 설정으로 체크 예외가 발생하면 커밋, 언체크 예외가 발생하면 롤백한다고 했다.
실제 그렇게 동작하는지 확인해보자.
package com.example.springtx.exception;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.context.TestConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.transaction.annotation.Transactional;
import static org.assertj.core.api.Assertions.*;
@Slf4j
@SpringBootTest
public class RollbackTest {
@Autowired RollbackService rollbackService;
@Test
void runtimeException() {
assertThatThrownBy(rollbackService::runtimeException)
.isInstanceOf(RuntimeException.class);
}
@Test
void checkedException() {
assertThatThrownBy(rollbackService::checkedException)
.isInstanceOf(MyException.class);
}
@Test
void checkedRollbackFor() {
assertThatThrownBy(rollbackService::rollbackFor)
.isInstanceOf(MyException.class);
}
@TestConfiguration
static class RollbackTestConfig {
@Bean
RollbackService rollbackService() {
return new RollbackService();
}
}
static class RollbackService {
/**
* 런타임 예외(언체크 예외)시 롤백 확인
* */
@Transactional
public void runtimeException() {
log.info("call runtimeException");
throw new RuntimeException();
}
/**
* 체크 예외 발생 시 커밋 확인
* */
@Transactional
public void checkedException() throws MyException {
log.info("call checkedException");
throw new MyException();
}
/**
* 체크 예외 rollbackFor 지정 시 롤백 확인
* */
@Transactional(rollbackFor = MyException.class)
public void rollbackFor() throws MyException {
log.info("call checkedException rollbackFor");
throw new MyException();
}
}
static class MyException extends Exception {
}
}
RollbackService 클래스에는 세 개의 메소드가 있다. runtimeException(), checkedException(), rollbackFor().
runtimeException() 메소드를 실행하면 언체크 예외를 발생시키고 이는 롤백을 하게 된다.
그 결과를 확인하는 테스트 코드는 RollbackTest.runtimeException()이다.
그리고 실제 커밋을 하는지 롤백을 하는지 로그로 확인해보기 위해서는 다음 설정이 application.yml 파일에 필요하다.
그 다음, 체크 예외를 발생시키면 커밋을 하는 것을 확인하는 테스트 코드는 RollbackTest.checkedException()이다.
RollbackTest.checkedException() 결과
커밋 로그가 찍힌다.
이제 체크 예외를 발생시켰지만 rollbackFor로 해당 체크예외를 지정해 놓으면 커밋이 아닌 롤백을 하는지 확인해보는 테스트 코드는 RollbackTest.checkedRollbackFor()이다.
RollbackTest.checkedRollbackFor()결과
롤백 로그가 찍힌다.
그럼 왜 체크 예외는 커밋이고 언체크 예외는 롤백일까?
예외와 트랜잭션 커밋, 롤백
스프링은 왜 체크 예외는 커밋, 언체크 예외는 롤백할까?
스프링은 기본적으로 체크 예외는 비즈니스 의미가 있을 때 사용하고, 런타임 예외는 복구가 불가능한 예외로 가정한다.
체크 예외 자체를 개발자가 이 예외가 터지는 것 자체가 비즈니스적으로 의미가 있다라고 판단한 예외라고 스프링은 가정하는 것.
비즈니스적으로 의미가 있다라고 판단한 예외란 또 어떤걸까? 아래와 같은 비즈니스 요구사항이 있다고 가정해보자.
비즈니스 요구사항
정상 처리: 주문시 결제를 성공하면 주문 데이터를 저장하고 결제 상태를 '완료'로 처리한다.
시스템 예외: 주문시 내부 복구 불가능한 예외(SQL 에러, 네트워크 에러, 시스템 장애 등)가 발생하면 전체 데이터를 롤백한다.
비즈니스 예외: 주문시 결제 잔고가 부족하면 주문 데이터를 저장하고 결제 상태를 '대기'로 처리한다. 이 경우, "고객에게 잔고 부족을 알리고 별도의 계좌로 입금하도록 안내한다."
이 때, 결제 잔고가 부족하면 NotEnoughMoneyException 이라는 체크 예외가 발생한다고 가정해보면, 이 예외는 시스템에 문제가 있어서 발생하는 예외가 아니다. 시스템은 정상 동작해도 비즈니스 상황적으로 문제가 되기 때문에 발생한 예외이다. 이런 예외를 비즈니스 예외라고 한다. 위 요구사항에서 결제 상태를 대기로 처리하는 것 자체가 롤백될 이유가 없다는 소리다.
중요한 건 예외는 시스템 예외와 비즈니스 예외로 항상 분기되고 비즈니스 예외는 시스템적으로 문제가 생긴게 아닌것임을 인지하는것이 중요하다.
스프링과 데이터베이스를 사용할 때 @Transactional 애노테이션을 사용해서 트랜잭션을 시작하고 종료하는데, 이 @Transactional 애노테이션을 사용하는 것을 '선언적 트랜잭션'이라고 한다. 근데 이 선언적 트랜잭션을 사용할 때 주의할 점이 있다.
트랜잭션 프록시 객체
우선 @Transactional이 달려있는 클래스 또는 메소드를 스프링이 실행할 때 쭉 돌면서 찾는다. 찾으면 빈으로 등록하는데 이때, 등록되는 것은 실제 해당 객체가 아닌 '프록시'이다. 아래 그림을 보자.
위 그림처럼 실제 Service에 @Transactional 애노테이션이 클래스 단위로 붙든, 특정 메소드에 붙든 있기만 하면 해당 클래스를 프록시로 만든다. 그리고 그 프록시는 실제 Service를 상속받는다. 여기서 이 프록시가 스프링 컨테이너에 올라가기 때문에 애플리케이션이 실행하고 특정 지점에서 (컨트롤러가 됐던, 다른 서비스가 됐던) 이 Service를 주입받으면 그 주입받은 녀석은 프록시가 된다.
근데 해당 클래스에서 2개의 메소드 중 하나는 @Transactional이 붙고 하나는 붙지 않았다면 어떻게 동작할까?
`external()` 메소드와 `internal()` 메소드가 있을 때, `internal()` 메소드에만 @Transactional 애노테이션이 달려있다. 그리고 `external()` 메소드에서 `internal()` 메소드를 호출한다. 이 경우, 트랜잭션이 발동하지 않는다.
왜 그럴까? 순차적인 흐름으로 살펴보자.
1. 최초 `external()` 메소드가 호출될 때, @Transactional이 달려있지 않지만, `internal()` 메소드가 @Transactional이 달려있으므로 스프링은 프록시 객체 CallService$$CGLIB를 만든다.
2. 외부에서 이 CallService를 주입받으면 프록시 객체가 주입된다.
3. 외부에서 이 주입받은 CallService의 `external()` 메소드를 호출하면 프록시 객체의 `external()`이 호출된다.
4. 실제 객체에서 @Transactional이 붙지 않았기 때문에 트랜잭션은 동작하지 않는다.
5. 트랜잭션이 붙지 않은 상태에서 `external()` 메소드를 호출하는데 `external()` 메소드를 호출할 때 프록시는 자기가 참조하고 있는 실제 객체의 `external()` 메소드를 호출한다.
6. 실제 객체의 `external()` 메소드에서 `internal()` 메소드를 호출해봐야 프록시에서 트랜잭션을 실행하지 않은 상태이므로 여전히 트랜잭션은 실행되지 않는다.
즉, 아래 그림이 위 흐름이라고 보면 된다.
결론은, `internal()`에 @Transactional 애노테이션이 있지만, 같은 클래스의 `external()`이 @Transactional이 없고, 최초에 호출된 건 `external()` 이기 때문에 트랜잭션을 적용하지 않은 상태에서 프록시 객체는 그저 실제 객체에게 `external()`을 위임한다. 그럼 실제 객체의 `external()`이 내부적으로 `internal()`을 호출해봤자 트랜잭션은 적용되지 않는것이다.
그럼 이를 해결하려면 어떻게 할까? 클래스를 분리하는게 가장 간단한 방법이다.
클래스를 분리하여 내부 호출을 피하기
문제의 원인은 `external()`, `internal()` 메소드가 같은 클래스인데 `external()`은 @Transactional이 붙지 않고 `internal()`은 붙어있기에 스프링은 해당 클래스를 프록시 객체로 만들어 스프링 컨테이너에 올리고 실제로 클라이언트가 주입받는 것 역시 이 프록시 객체이다.
그래서 이 프록시 객체는 `external()`이 @Transactional이 붙지 않았기에 트랜잭션을 실행하지 않은 상태에서 실제 객체에게 위임한다. 실제 객체는 그대로 본인의 `internal()` 메소드를 호출하기 때문에 트랜잭션은 실행되지 않는다. 그럼 `external()`과 `internal()`의 클래스를 분리하자.
@RequiredArgsConstructor
static class CallService {
private final InternalService internalService;
public void external() {
log.info("call external");
printTxInfo();
internalService.internal();
}
}
static class InternalService {
@Transactional
public void internal() {
log.info("call internal");
printTxInfo();
}
}
자, 이제 이렇게 분리된 두 클래스는 어떤 차이를 보일까? `external()`이 `internalService.internal()`을 호출하지만, `internalService.internal()`은 다른 클래스의 메소드이다. 사용하기 위해선 주입받아야 하고 주입받는건? InternalService$$CGLIB이다.
그럼 이 프록시 객체는 `internal()`이 @Transactional이 있는지 확인한 후 있기 때문에 트랜잭션을 실행한 상태에서 실제 객체에게 위임한다. 이렇게 문제를 해결할 수 있다.
그림으로 보면 좀 더 명확하다.
결론
앞으로 트랜잭션을 달았는데도 트랜잭션이 먹지 않았다면, 이런 현상이지 않을까를 고민해보자.
각각의 데이터 접근 기술들은 트랜잭션을 처리하는 방식에 차이가 있다. 예를 들어 JDBC 기술과 JPA 기술은 트랜잭션을 사용하는 코드 자체가 다르다.
JDBC 트랜잭션 코드 예시
public void accountTransfer(String fromId, String toId, int money) throws SQLException {
Connection con = dataSource.getConnection();
try {
con.setAutoCommit(false); //트랜잭션 시작 //비즈니스 로직
bizLogic(con, fromId, toId, money);
con.commit(); //성공시 커밋
} catch (Exception e) {
con.rollback(); //실패시 롤백
throw new IllegalStateException(e);
} finally {
release(con);
}
}
JPA 트랜잭션 코드 예시
public static void main(String[] args) {
//엔티티 매니저 팩토리 생성
EntityManagerFactory emf = Persistence.createEntityManagerFactory("jpabook");
EntityManager em = emf.createEntityManager(); //엔티티 매니저 생성
EntityTransaction tx = em.getTransaction(); //트랜잭션 기능 획득
try {
tx.begin(); //트랜잭션 시작 logic(em); //비즈니스 로직 tx.commit();//트랜잭션 커밋
} catch (Exception e) {
tx.rollback(); //트랜잭션 롤백
} finally {
em.close(); //엔티티 매니저 종료
}
emf.close(); //엔티티 매니저 팩토리 종료
}
JDBC 기술을 사용하다가 JPA 기술로 변경하게 되면 트랜잭션을 사용하는 코드도 모두 함께 변경해야 한다. 스프링은 이런 문제를 해결하기 위해 트랜잭션 추상화를 제공한다. 트랜잭션을 사용하는 입장에서는 스프링 트랜잭션 추상화를 통해 둘을 동일한 방식으로 사용할 수 있게 되는 것이다. 스프링은 PlatformTransactionManager라는 인터페이스를 통해 트랜잭션을 추상화한다.
스프링은 트랜잭션을 추상화해서 제공할 뿐만 아니라, 실무에서 주로 사용하는 데이터 접근 기술에 대한 트랜잭션 매니저의 구현체도 제공한다. 우리는 필요한 구현체를 스프링 빈으로 등록하고 주입 받아서 사용하기만 하면 된다.
그런데, 그럴 필요도 없다. 스프링 부트는 어떤 데이터 접근 기술을 사용하는지를 자동으로 인식해서 적절한 트랜잭션 매니저를 선택해서 스프링 빈으로 등록해주기 때문에 트랜잭션 매니저를 선택하고 등록하는 과정도 생략할 수 있다. 예를 들어서 JdbcTemplate, Mybatis를 사용하면 DataSourceTransactionManager를 스프링 빈으로 등록하고, JPA를 사용하면 JpaTransactionManager를 스프링 빈으로 등록해준다.
스프링 트랜잭션 사용 방식
PlatformTransactionManager를 사용하는 방법은 크게 2가지가 있다.
선언적 트랜잭션 관리
@Transactional 애노테이션 하나만 선언해서 매우 편리하게 트랜잭션을 적용하는 것을 선언적 트랜잭션 관리라 한다.
프로그래밍 방식의 트랜잭션 관리
트랜잭션 매니저 또는 트랜잭션 템플릿 등을 사용해서 트랜잭션 관련 코드를 직접 작성하는 것을 프로그래밍 방식의 트랜잭션 관리라 한다.
이 방식의 문제는 애플리케이션 코드가 트랜잭션이라는 기술 코드와 강하게 결합된다는 점이다. 쉽게 말해 서비스 코드 안에 트랜잭션 처리 코드가 같이 있다는 말이다.
선언적 트랜잭션과 AOP
@Transactional을 통한 선언적 트랜잭션 관리 방식을 사용하게 되면 기본적으로 프록시 방식의 AOP가 적용된다.
트랜잭션을 처리하기 위한 프록시를 도입하기 전에는 서비스의 로직에서 트랜잭션을 직접 시작했다. 그래서 아래와 같은 코드 모양새가 된다. 프로그래밍 방식의 트랜잭션 관리라고 보면 된다.
트랜잭션을 처리하기 위한 프록시를 적용하면 트랜잭션을 처리하는 객체와 비즈니스 로직을 처리하는 서비스 객체를 명확하게 분리할 수 있다. 그래서 아래와 같은 그림과 코드가 된다.
public void logic() {
//트랜잭션 관련 코드 제거, 순수 비즈니스 로직만 남음
bizLogic(fromId, toId, money);
}
위의 프로그래밍 방식의 트랜잭션 관리랑 비교해보면 정말 순수하고 깔끔한 코드이다.
트랜잭션 프록시가 트랜잭션 처리 로직을 모두 가져간 상태이다. 그리고 트랜잭션을 시작한 후에 실제 서비스를 대신 호출해준다.
프록시 도입 후 전체 과정
트랜잭션은 커넥션에 con.setAutoCommit(false)를 지정하면서 시작한다.
같은 트랜잭션을 유지하려면 같은 데이터베이스 커넥션을 사용해야 한다. 이것을 위해 스프링 내부에서는 트랜잭션 동기화 매니저가 사용된다.
JdbcTemplate을 포함한 대부분의 데이터 접근 기술들은 트랜잭션을 유지하기 위해 내부에서 트랜잭션 동기화 매니저를 통해 리소스(커넥션)를 동기화한다.
스프링의 트랜잭션은 매우 중요한 기능이고, 전세계 누구나 사용하는 기능이다. 스프링은 트랜잭션 AOP를 처리하기 위한 모든 기능을 제공한다. 스프링 부트를 사용하면 트랜잭션 AOP를 처리하기 위해 필요한 스프링 빈들도 자동으로 등록해준다.
개발자는 트랜잭션 처리가 필요한 곳에 @Transactional 애노테이션만 붙여주면 된다. 스프링의 트랜잭션 AOP는 이 애노테이션을 인식해서 트랜잭션을 처리하는 프록시를 적용해준다.
트랜잭션 적용 확인
실제로 저렇게 @Transactional 애노테이션만 붙여주면 정말 트랜잭션이 적용되는 걸까? 눈으로 봐야만 확신할 수 있는 우리는 직접 확인해봐야겠다. 그러기 위해 다음과 같은 테스트 코드를 준비해보자.
package cwchoiit.tx.apply;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.aop.support.AopUtils;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.context.TestConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.support.TransactionSynchronizationManager;
import static org.assertj.core.api.Assertions.assertThat;
@Slf4j
@SpringBootTest
public class TxBasicTest {
@Autowired
BasicService basicService;
@Test
void proxyCheck() {
log.info("aop class = {}", basicService.getClass());
assertThat(AopUtils.isAopProxy(basicService)).isTrue();
}
@Test
void txTest() {
basicService.tx();
basicService.nonTx();
}
@TestConfiguration
static class TxApplyBasicConfig {
@Bean
BasicService basicService() {
return new BasicService();
}
}
static class BasicService {
@Transactional
public void tx() {
log.info("call Tx");
log.info("tx active = {}", TransactionSynchronizationManager.isActualTransactionActive());
}
public void nonTx() {
log.info("call Non Tx");
log.info("tx active = {}", TransactionSynchronizationManager.isActualTransactionActive());
}
}
}
proxyCheck() 실행
AopUtils.isAopProxy()는 선언적 트랜잭션 방식에서 스프링 트랜잭션은 AOP를 기반으로 동작한다. @Transactional을 메서드나 클래스에 붙이면 해당 객체는 트랜잭션 AOP 적용 대상이 되고, 결과적으로 실제 객체 대신에 트랜잭션을 처리해주는 프록시 객체가 스프링 빈에 등록된다. 그리고 주입을 받을 때도 실제 객체 대신에 프록시 객체가 주입된다.
클래스 이름을 출력해보면, 아래와 같은 이름의 프록시 클래스가 출력된다.
aop class = class cwchoiit.tx.apply.TxBasicTest$BasicService$$SpringCGLIB$$0
근데 어떻게 프록시가 주입될까?
스프링 컨테이너에 트랜잭션 프록시 등록
@Transactional 애노테이션이 특정 클래스나 메서드에 하나라도 있으면 트랜잭션 AOP는 프록시를 만들어서 스프링 컨테이너에 등록한다. 그리고 실제 basicService 객체 대신에 프록시인 BasicService$$SpringCGLIB를 스프링 빈에 등록한다. 그리고 프록시는 내부에 실제 BasicService를 참조하게 된다. 여기서 핵심은 실제 객체 대신에 프록시가 스프링 컨테이너에 등록되었다는 점이다.
클라이언트인 txBasicTest는 스프링 컨테이너에 BasicService로 의존관계 주입을 요청하는데 스프링 컨테이너에는 실제 객체 대신에 프록시가 스프링 빈으로 등록되어 있기 때문에 프록시를 주입한다. 타입은 BasicService이고 인스턴스가 프록시일 뿐이다.
왜냐하면 프록시는 BasicService를 상속해서 만들어지기 때문에 다형성을 활용할 수 있기 때문이다. 따라서 BasicService 대신에 프록시인 BasicService$$SpringCGLIB를 주입받을 수 있다.
txTest() 실행
TransactionSynchronizationManager.isActualTransactionActive()는 현재 쓰레드에 트랜잭션이 적용되어 있는지 확인할 수 있는 기능이다. 결과가 true면 트랜잭션이 적용되어 있는 것이다. 트랜잭션의 적용 여부를 가장 확실하게 확인할 수 있다.
2024-12-08T18:22:49.688+09:00 INFO 18734 --- [ Test worker] cwchoiit.tx.apply.TxBasicTest : call Tx
2024-12-08T18:22:49.688+09:00 INFO 18734 --- [ Test worker] cwchoiit.tx.apply.TxBasicTest : tx active = true
2024-12-08T18:22:49.690+09:00 INFO 18734 --- [ Test worker] cwchoiit.tx.apply.TxBasicTest : call Non Tx
2024-12-08T18:22:49.690+09:00 INFO 18734 --- [ Test worker] cwchoiit.tx.apply.TxBasicTest : tx active = false
트랜잭션 적용 위치
이번에는 @Transactional 애노테이션의 적용 위치에 따른 우선순위를 확인해보자. 스프링에서 우선순위는 항상 더 디테일하고 자세한 것이 높은 우선순위를 가진다. 이것만 기억하면 스프링에서 발생하는 대부분의 우선순위를 쉽게 기억할 수 있다. 그리고 더 구체적인 것이 더 높은 우선순위를 가지는 것은 상식적으로 자연스럽다. 예를 들어, 메서드와 클래스에 애노테이션을 붙일 수 있다면, 더 구체적인 메서드가 더 높은 우선순위를 가진다. 인터페이스와 해당 인터페이스를 구현한 클래스에 애노테이션을 붙일 수 있다면 더 구체적인 클래스가 더 높은 우선순위를 가진다.
트랜잭션을 사용할 때는 다양한 옵션을 사용할 수 있다. 그런데 어떤 경우에는 옵션을 주고, 어떤 경우에는 옵션을 주지 않으면 어떤 것이 선택될까? 예를 들어 읽기 전용 트랜잭션 옵션을 사용하는 경우와 아닌 경우를 비교해보자. 위 코드의 경우 클래스 레벨에는 읽기 전용 옵션`@Transactional(readOnly = true)`이 붙어 있다. 그런데 write() 메서드에는 `@Transactional`만 붙어있다. 이러면 당연히 메서드가 더 구체적이기 때문에 메서드에 있는 쓰기도 가능한 트랜잭션이 적용된다.
클래스에 적용하면 메서드는 자동 적용
위 코드에서 read()의 경우 메서드에 @Transactional 애노테이션이 붙지 않았다. 이런 경우 더 상위 개념인 클래스를 확인한다. 클래스에 @Transactional(readOnly = true)가 붙어 있다. 따라서 트랜잭션이 적용되고 읽기 전용 모드로 진행된다. 참고로 기본 옵션이 readOnly는 false이기 때문에 위 코드처럼 생략한다.
인터페이스에 @Transactional 적용
인터페이스에도 @Transactional 애노테이션을 적용할 수는 있다. 이 경우 다음 순서로 적용된다. 구체적인 것이 더 높은 우선순위를 가진다고 생각하면 바로 이해가 될 것이다.
클래스의 메서드 (우선순위가 가장 높다)
클래스의 타입
인터페이스의 메서드
인터페이스의 타입 (우선순위가 가장 낮다)
클래스의 메서드를 찾고, 만약 없으면 클래스의 타입을 찾고, 만약 없으면 인터페이스의 메서드를 찾고, 그래도 없으면 인터페이스의 타입을 찾는다. 그런데 인터페이스에 @Transactional 애노테이션을 사용하는 것은 스프링 공식 매뉴얼에도 권장하지 않는 방법이다. 그러니까 이렇게 코드는 작성 하지 않았으면 한다. 가급적 구체 클래스에 @Transactional을 사용하자. 왜 권장하지 않냐면, 스프링이 프록시를 만들어내는 방식 중 하나인 CGLIB는 구체 클래스를 상속받아 만들어낸다. 그래서 인터페이스까지 올라가지 않고 구체클래스를 상속받은 프록시를 만들기 때문에 AOP가 적용되지 않는 사례가 있기 때문이다. 지금은 인식문제가 없다. 과거, 그러니까 스프링 5.0 이전에는 이런 인식 문제가 발생했는데 지금은 그 부분을 많이 개선했지만 그래도 불구하고 구체 클래스에 @Transactional을 사용하자!
@Transactional은 private 메서드에는 적용되지 않는다.
이건 CGLIB를 통해 프록시를 만들어내는 스프링의 방식에서 비롯된건데 CGLIB로 프록시를 만들땐 실제 객체를 상속받아 프록시를 만든다. 상속받아 프록시를 만들고 그 프록시 안에 실제 객체를 참조하기까지 한다. 참조하고 있어야 실제 객체의 메서드를 호출할테니. 그런데 상속받아 만들어 기존 객체의 메서드를 재정의하여 만약 @Transactional 애노테이션이 붙은 메서드라면 트랜잭션 기능을 적용한 재정의 메서드가 만들어진다. `private` 접근 제어자는 상속받는다고 해도 재정의할 수 없다. 아예 자식 객체에서 호출조차 불가능하다. 이러한 이유 때문에 private 메서드는 @Transactional 애노테이션이 적용되지 않는 것이다. 이 말은, 스프링이 지원하는 애노테이션을 붙였을때 프록시로 만들어주는 모든 애노테이션이 다 동일하게 이렇게 동작한다는 말이다. 여기까지는 기술적인 이유이다.
그럼, 논리적인 이유는 뭘까? `private` 접근 제어자는 트랜잭션이 필요할까? `private` 이라는 키워드는 나 자신만이 이 메서드를 사용하고 싶다, 외부로 노출하고 싶지 않다는 강력한 의지 표현이다. 그럼 외부에 노출하고 싶지 않은데 트랜잭션과 상호작용할 필요가 있을까? 사실 논리적으로 생각해도 이건 말이 맞지 않기도 하다.
결론적으로, @Transactional 애노테이션은 `private`에는 적용되지 않는다.
참고로, 스프링 부트 3.0 이전에는 protected, default 접근 제어자 역시도 @Transactional 애노테이션을 달아도 트랜잭션이 적용되지 않았다. 오로지 `public`만이 가능했는데 3.0 이후부터는 `private`을 제외하고 다 가능하다.
트랜잭션 AOP 주의 사항 - 초기화 시점
스프링 초기화 시점에는 트랜잭션 AOP가 적용되지 않을 수 있다. 타이밍 이슈 때문인데 코드를 보자.
@EventListener(ApplicationReadyEvent.class) 애노테이션은 이 스프링이 완전히 준비가 다 끝난 후 호출되는 이벤트고 그 이벤트를 캐치하는 리스너 애노테이션이다. 따라서 AOP가 모두 적용된 상태 이후에 호출되므로 정상적으로 트랜잭션이 적용된다.
정리를 하자면
모든 데이터베이스와의 연동은 트랜잭션안에서 이루어져야 한다. 그래서 JDBC를 직접 사용하든 JPA, Mybatis 등 어떤 기술을 사용하더라도 트랜잭션이 사용된다. 그런데 문제는 각 기술마다 트랜잭션을 사용하는 방법이 다르다는 것이다. 그래서 스프링은 이 트랜잭션을 사용하는 방법을 추상화했다. 그게 PlatformTransactionManager이다. 이 표준을 각 기술별로 구현한 구현체를 가져다가 사용만 하면 되는데 이 구현체 역시도 스프링이 만들어놨기 때문에 아주 편리하게 사용할 기술만 라이브러리로 내려받으면 된다.
그런데, 여기서 한 발 더 나아가서 스프링이 이 PlatformTransactionManager를 주입받아 사용하는 것조차 귀찮고, 트랜잭션 적용 코드와 비즈니스 로직이 들어있는 서비스 코드가 합쳐져 순수한 서비스 코드를 망치게 하니 스프링은 @Transactional 애노테이션을 만들어 두었다. 이 애노테이션 하나만 있으면 AOP, 프록시 기술을 사용하여 순수한 서비스 코드를 작성할 수 있다.
지금까지 이 @Transactional 애노테이션의 기본 사용 방법과 주의할 사항들을 알아보았다. 그럼 다음 포스팅에서는 이 @Transactional 애노테이션이 가지고 있는 여러 속성들을 알아보고 거기서 중요한 부분이 굉장히 많으니 그 부분에 대해서 심도있게 알아보자!
ItemService 인터페이스이다. 물론, 서비스는 인터페이스를 따로 만들지 않아도 된다고 생각한다. 이것도 고민거리 중 하나인데 생각해보면 서비스는 최대한 순수한 자바 코드를 사용해서 구현하면 할수록 좋다. 그러려고 노력하고 있고. 그렇기 때문에 서비스는 특정 기술에 의존하는 게 비교적 적다. 그럼 기술을 갈아끼우는 작업이 없는데 인터페이스가 굳이 필요할까?에 대한 고민이 첫번째.
그럼에도 불구하고 인터페이스를 만들고 그 구현체를 만들었긴 했으니 일단 계속 진행하자.
ItemServiceV1
package hello.itemservice.service;
import hello.itemservice.domain.Item;
import hello.itemservice.repository.ItemRepository;
import hello.itemservice.repository.ItemSearchCond;
import hello.itemservice.repository.ItemUpdateDto;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import java.util.List;
import java.util.Optional;
@Service
@RequiredArgsConstructor
public class ItemServiceV1 implements ItemService {
private final ItemRepository itemRepository;
@Override
public Item save(Item item) {
return itemRepository.save(item);
}
@Override
public void update(Long itemId, ItemUpdateDto updateParam) {
itemRepository.update(itemId, updateParam);
}
@Override
public Optional<Item> findById(Long id) {
return itemRepository.findById(id);
}
@Override
public List<Item> findItems(ItemSearchCond cond) {
return itemRepository.findAll(cond);
}
}
ItemService를 구현한 구현체이다. 그리고 이 서비스는 지금 코드로만 보면 단순히 ItemRepository에 위임하고 있는 수준이다.
그런데 ItemRepository는 인터페이스고 구현체가 다양하다. JdbcTemplate, Mybatis, Spring Data JPA, QueryDsl을 사용한 여러 구현체가 있는데 여기서 나의 고민이 발생한다.
구현 기술이 바뀌더라도 사용하는 클라이언트 코드에는 변경이 없도록 의존관계를 주입받아 사용하여 OCP 원칙을 지키는 설계를 반드시 지켜야 하는가?
아주 좋은 설계이고 유지보수에 굉장히 도움이 되는 설계이다. 그런데 이 원칙을 고수하고자 하면 이러한 모양이 그려진다.
생각해보면 Spring Data JPA를 사용하면, 그냥 JpaRepository를 상속받은 인터페이스를 하나 만들면 Spring Data JPA가 알아서 구현체를 만들어주기 때문에 서비스는 그냥 JpaRepository를 상속받은 인터페이스만 주입받으면 된다.
그런데 서비스는 ItemRepository를 주입받기 때문에 이 ItemRepository를 구현하는 구현체를 만들고 그 구현체가 Spring Data JPA를 사용하도록 중간 다리 하나가 더 필요해진다.
만약, 아래와 같은 그림으로 설계하면 어떨까?
서비스는 바로 Spring Data JPA를 사용하기 위해 만들어진 Repository를 주입받는 것이다.
이러면 중간 다리도 필요없고 복잡한 구조도 사라지고 그림이 매우 간단해진다. 가장 좋은건 개발자가 단순하게 바로 JpaRepository를 상속받은 인터페이스를 직접 주입받아 사용하면 되니까 개발 속도가 빨라진다는 점이다.
트레이드 오프
이 부분이 트레이드 오프가 된다.
1 → DI, OCP를 지키기 위해 중간에 어댑터를 도입하고 더 많은 코드를 유지하거나
2 → 어댑터를 제거하고 구조를 단순하게 가져가지만, DI와 OCP를 포기하고 ItemService 코드를 직접 변경한다.
1번의 장점
자, DI와 OCP를 지킨다면 추후 데이터 접근 기술이 바뀌어도 서비스 코드는 변경할 필요가 전혀 없다. 이 서비스가 의존하는건 인터페이스지 구현체가 아니기 때문에 어떤 기술을 사용하던지 그 인터페이스를 구현한 구현체만 만들어 빈으로 등록하면 된다. 즉, 구조의 안정성이 생긴다.
1번의 단점
개발 속도와 개발의 편리성이 떨어지고 코드가 많아진다. 쉽게 말해, 안해도 되는 작업을 구조의 안정성을 위해 해야하는 공수가 생긴다.
→ 정답은 없다.
내가 내린 결론은 정답은 없다이다. 만약, 프로젝트 규모가 굉장히 크고 추후 기술의 변경점이 반드시 생길 것 같다고 판단되면 구조의 안정성을 가져가는게 좋은 판단이라고 생각된다. 그러나, 빠른 개발이 가장 우선이고 추후 기술의 변경점이 많지 않을 것 같다고 판단되면 실용적인 구조가 더 좋은 판단이라고 생각된다. 쉽게 말해, 현재 상황에 맞게 적절한 선택을 해야 한다는 말이다.
다양한 데이터 접근 기술 조합
또 다른 주제로, 이렇게 여러 기술을 배워봤는데 그래서 어떤 기술을 선택하면 좋을까? 이 부분 역시 하나의 정답이 있는건 아니라고 생각한다. JdbcTemplate이나 Mybatis와 같은 기술들은 SQL을 직접 작성해야 하는 단점은 있지만 기술이 단순하기 때문에 SQL에 익숙한 개발자라면 러닝 커브가 굉장히 낮다.
JPA, 스프링 데이터 JPA, QueryDsl과 같은 기술들은 개발 생산성을 혁신할 수 있지만, 학습 곡선이 높아 이런 부분을 감안해야 한다. 그리고 매우 복잡한 통계 쿼리를 주로 작성하는 경우에는 잘 맞지 않는다.
그래서, 메인 시나리오는 이렇다.
→ 스프링 데이터 JPA, QueryDsl을 기본으로 사용하고 복잡하고 통계형 쿼리를 사용해야 하는 경우에 JdbcTemplate이나 MyBatis를 함께 사용하는 것.
거의 대부분의 경우 스프링 데이터 JPA와 QueryDsl만으로 문제가 해결이 되는데 가끔 네이티브 SQL을 사용해야 하는 경우가 생기긴 한다. 그런 경우에 JdbcTemplate, Mybatis를 사용하면 된다.
트랜잭션 매니저 선택
JPA, Spring Data JPA, QueryDsl은 모두 JPA 기술을 사용하는 것이기 때문에 트랜잭션 매니저로 JpaTransactionManager를 사용한다. 위 기술들을 사용하면 스프링 부트는 자동으로 JpaTransactionManager를 스프링 빈으로 등록한다. 그런데 JdbcTemplate, Mybatis와 같은 기술들은 DataSourceTransactionManager를 사용한다. 따라서 JPA와 JdbcTemplate 두 기술을 함께 사용하면 트랜잭션 매니저가 달라진다. 결국 트랜잭션을 하나로 묶을 수 없는 문제가 발생한다. 어떻게 하면 되지? 트랜잭션을 하나로 묶을 수 없다면 데이터베이스 커넥션이 달라진다는 얘기고 커넥션이 달라진다는 것은 두 작업간의 동시적으로 동기화를 할 수 없다는 얘긴데 말이다. 동기화가 안된다는 것은 롤백과 커밋이 불가능하다는 얘기다.
JpaTransactionManager의 지원
위 걱정은 할 필요가 없다. JpaTransactionManager는 놀랍게도 DataSourceTransactionManager가 제공하는 기능도 대부분 제공한다. JPA라는 기술도 결국 내부에는 다 DataSource와 JDBC 커넥션을 사용할 수 밖에 없기 때문이다. 따라서 JdbcTemplate, Mybatis와 함께 사용할 수 있다. 결과적으로 JpaTransactionManager만 스프링 빈에 등록하면 JPA, JdbcTemplate, Mybatis 모두를 하나의 트랜잭션으로 묶어 사용할 수 있다. 그 말은 커밋도 롤백도 다 가능해진다는 의미다.
주의할 점은, JPA와 JdbcTemplate을 함께 사용할 경우 JPA 플러시 타이밍을 고려해야 한다. JPA는 데이터를 변경할 때 변경 사항을 즉시 데이터베이스에 반영하는 게 아니라 커밋 시점에 변경 사항을 데이터베이스에 반영한다. 쓰기 지연이라는 기술을 내부적으로 사용하기 때문에 그렇다. 그런데 이런 경우에 하나의 트랜잭션 안에서 JPA를 통해 데이터를 변경한 다음 JdbcTemplate을 호출해 사용하는 경우 JdbcTemplate에서는 JPA가 변경한 데이터를 읽지 못하는 문제가 발생한다. 같은 커넥션이라고 해도 이건 커넥션이나 트랜잭션의 문제가 아니라 기술이 다르기 때문에 JPA가 처리하는 방식이 커밋 시점에 한번에 쓰기에 대한 쿼리를 날리기 때문에 그렇다. 그래서 이렇게 한 트랜잭션에서 JPA로 데이터를 변경한 다음 JdbcTemplate을 호출하는 경우가 있다면 JdbcTemplate을 호출하기 전에 JPA가 제공하는 플러시를 사용해서 JPA의 변경 내역을 바로 데이터베이스에 적용해줘야 한다.
QueryDsl은 뭐고 왜 생겼을까? 기존 JPA를 사용할 때 다 좋은데 아쉬운 점은 동적쿼리에 취약하다는 점이다. JDBC도 마찬가지로 동적 쿼리가 매우 불편하다. 둘 다 동적으로 쿼리를 만드려면 코드가 매우 지저분해진다. 다음 코드를 보자.
@Override
public List<Item> findAll(ItemSearchCond cond) {
String jpql = "SELECT i FROM Item i";
Integer maxPrice = cond.getMaxPrice();
String itemName = cond.getItemName();
if (StringUtils.hasText(itemName) || maxPrice != null) {
jpql += " where";
}
boolean andFlag = false;
if (StringUtils.hasText(itemName)) {
jpql += " i.itemName like concat('%',:itemName,'%')";
andFlag = true;
}
if (maxPrice != null) {
if (andFlag) {
jpql += " and";
}
jpql += " i.price <= :maxPrice";
}
log.info("jpql={}", jpql);
TypedQuery<Item> query = em.createQuery(jpql, Item.class);
if (StringUtils.hasText(itemName)) {
query.setParameter("itemName", itemName);
}
if (maxPrice != null) {
query.setParameter("maxPrice", maxPrice);
}
return query.getResultList();
}
이건 JPA로 동적 쿼리를 작성하는 부분이다. 보기만 해도 그래서 결국 어떤 쿼리를 날릴까?에 대한 굉장한 의문이 생긴다.
그리고 더 큰 문제는 동적 쿼리를 만들어 낼 때 문자열에 문자열을 추가하는데 이게 자칫 잘못했다가는 SQL에 문제가 생길 수도 있다. 다음 코드를 보자.
String sql =
"select * from member" +
"where name like ?" +
"and age between ? and ?"
자칫 보면 아무런 문제가 없어보인다. 그러나, 지금 저 문자열은 띄어쓰기가 제대로 되어 있지 않아서 SQL이 문제가 발생한다. 저 문자열을 풀어보면 이렇게 된다.
String sql = "select * from memberwhere name like ?and age between ? and ?"
이건 문법 오류를 발생시킬 것이다. 그런데 더 큰 문제는 문자열이라서 컴파일 시에 문제를 뱉어내지 않는다. 그래서 개발자는 자칫 실수를 할 수 있다. 이 문제가 위 JPA에서 동적 쿼리를 만들어낼때도 동일하게 적용된다. 조건에 따라 쿼리에 문자열을 추가하고 있지 않은가?
그리고, SQL을 작성할 때 과연 컬럼명을 다 외우면서 작성할 수 있을까? 물론 외울 수도 있다. 그런데 외울 필요없이 그냥 자바 코드 작성하듯 (.) 찍으면 사용 가능한 필드가 보여지고 그런 편의성을 제공해주면 얼마나 좋을까? 이를 위해 QueryDsl이 만들어졌다.
그래서 QueryDsl은 이런 장점이 있다.
동적 쿼리를 작성할 때 매우매우 막강하다.
타입 세이프한 쿼리를 작성하기에 좋다.
왜 이런 장점이 있는지 하나씩 알아보자.
QueryDsl 설정
일단, 가장 단점이라고 하면 QueryDsl은 설정이 조금 귀찮다. 그러나 이 설정의 귀찮음을 몇배는 더 능가하는 막강한 기능을 제공하기 때문에 안 쓸 이유가 없다. 한번 사용하면 못 돌아온다. 설정 관련 포스팅이 이미 있다.
먼저 QueryDsl을 사용하기 위해서는 아래와 같이 JPAQueryFactory를 주입받아야 한다.
private final EntityManager em;
private final JPAQueryFactory queryFactory;
public JpaItemRepositoryV3(EntityManager em) {
this.em = em;
this.queryFactory = new JPAQueryFactory(em);
}
Spring Data JPA는 JPA랑 다른건가? Spring Data JPA가 무엇이고, 왜 탄생했는지를 시작해서 어떻게 사용하면 좋을지에 대한 포스팅을 작성하기로 했다.
최악의 EJB
아주 예전에 EJB(Enterprise Java Beans)라는 기술이 있었다. 자바 표준으로 제공하는 기술이었는데 이 기술을 사용하려면 정말 너무너무 어렵고 복잡하고 코드도 지저분하고 말도 아니었다. 그래서 사용자들은 피로감을 느꼈고, 오죽하면 순수한 자바로 다시 돌아가자라는 의미를 가진 POJO(Plan Old Java Object)라는 단어도 탄생할 지경이었다.
그래서 EJB의 지옥에서 탈출하기 위해 두명의 영웅이 탄생한다. 스프링의 창시자라고도 불리는 로드 존슨과 하이버네이트의 창시자 개빈 킹. 개빈 킹이라는 사람은 EJB의 엔티티빈을 사용하면서 데이터 접근 기술을 사용하려다가 "도저히 못해먹겠다. 이렇게 할 바에 내가 만드는 게 더 나을것 같다"라는 생각을 가지고 만든 하이버네이트가 곧 JPA라는 표준을 만들게 된다. 그러니까 역사적으로도 JPA라는 표준 기술보다 하이버네이트가 먼저 나왔다. 사람들이 하이버네이트에 열광을 하니 자바 진영에서 개빈 킹이라는 사람을 불러다가 이 기술을 표준화해서 자바 표준으로 하나 만들고 싶다라는 청을 했고 그렇게 만들어진게 JPA다.
그렇게 JPA라는 표준과 그 표준을 구현한 구현체 중 하나인 Hibernate가 있게 된다. 오픈소스를 기반으로 표준을 만들어 냈기 때문에 실용적일뿐더러 딱딱하고 고리타분한 표준이 아니라 사용자들이 훨씬 더 사용하기 쉽게 표준이 만들어졌다.
Spring Data JPA의 탄생
그래서 이렇게 스프링과 JPA가 한 묶음이 되어 사람들이 편리하게 개발을 하던 중 이런 고민이 생기게 된다. MongoDB, Redis, 관계형 데 이터베이스 등 데이터 접근 기술이 하도 방대하고 방식도 다른데 결국 컨셉은 데이터를 어딘가에 저장하고 그 데이터를 관리, 보관, 사용에 목적이 있지 않나? 그럼 이 데이터 접근 기술의 방식은 다를지언정 결국 CRUD라는 큰 컨셉이 동일하다 보니 이 또한 표준으로 만들어볼까? 라는 생각으로 만들어진 것이 바로 Spring Data 라는 표준이다. 그리고 그 표준을 따라 구현한 하나의 구현체가 Spring Data JPA가 있는 것이다. Spring Data Redis, Spring Data Mongo 등 여러가지 구현체가 있지만 결국 Spring Data라는 큰 표준을 두고 그 표준에 맞춰 구현 기술을 구현하되 각각의 특징에 맞게 구현된 것이다.
그리고 우리는 여기서 Spring Data JPA를 배울것이고 이는 JPA를 사용한 방식인 것이다.
이 Spring Data 표준은 결국 이런 것이다.
CRUD + 쿼리
동일한 인터페이스
페이징 처리
메서드 이름으로 쿼리 생성
스프링 MVC에서 ID값만 넘겨도 도메인 클래스로 바인딩
이게 다 결국 데이터 접근 기술들이 가지고 있는 특징들 아닌가? 그 안에 방식이 살짝 다를뿐 결국 목적은 여기에 있다. 그러다보니 이런 표준을 만들고 구현은 너네 입맛에 맞게 구현해라라고 표준이 만들어졌다.
Spring Data JPA 주요 기능
스프링 데이터 JPA는 JPA를 편리하게 사용할 수 있도록 도와주는 라이브러리이다. 수많은 편리한 기능을 제공하지만, 가장 대표적인 기능은 다음과 같다.
공통 인터페이스 기능
쿼리 메서드 기능
공통 인터페이스 기능
JpaRepository 인터페이스를 통해서 기본적인 공통 CRUD 기능을 제공한다.
공통화 가능한 기능이 거의 모두 포함되어 있다.
CrudRepository에서 지금은 findOne() → findById()로 변경되었다.
JpaRepository를 사용하는 방법은 정말 매우 간단한데, 그냥 아래와 같이 인터페이스를 상속만 받으면 된다.
public interface ItemRepository extends JpaRepository<Item, Long> {}
JpaRepository 인터페이스를 상속 받고, 제네릭에 관리할 <엔티티, 엔티티ID 타입>을 주면 된다.
그러면 JpaRepository가 제공하는 기본 CRUD 기능을 모두 사용할 수 있다.
어떻게 인터페이스만 상속받으면 위 기능을 다 사용할 수 있냐? 당연히 스프링 데이터 JPA 라이브러리에서 구현 클래스를 대신 만들어준다. 스프링을 사용하다보면 느끼겠지만 이런 유사한 기능이 정말 많다.
JpaRepository 인터페이스만 상속받으면, 스프링 데이터 JPA가 프록시 기술을 사용해서 구현 클래스를 만들어준다.
그리고 만든 구현 클래스의 인스턴스를 만들어서 스프링 빈으로 등록한다.
따라서 개발자는 구현 클래스 없이 인터페이스만 만들면 기본 CRUD 기능을 사용할 수 있다.
쿼리 메서드 기능
스프링 데이터 JPA는 인터페이스에 메서드만 적어두면, 메서드 이름을 분석해서 쿼리를 자동으로 만들어주고 실행해주는 기능을 제공한다. 다음 코드를 보자.
순수한 JPA 레포지토리
public List<Member> findByUsernameAndAgeGreaterThan(String username, int age) {
return em.createQuery("select m from Member m where m.username = :username and m.age > :age")
.setParameter("username", username)
.setParameter("age", age).getResultList();
}
순수하게 JPA만 사용할 경우에, 개발자는 이러한 JPQL을 작성해서 메서드로 만들어 두어야 한다.
스프링 데이터 JPA
public interface MemberRepository extends JpaRepository<Member, Long> {
List<Member> findByUsernameAndAgeGreaterThan(String username, int age);
}
이렇게 메서드 시그니처만 만들어두면, 스프링 데이터 JPA는 메서드 이름을 분석해서 필요한 JPQL을 만들고 실행해준다. 이게 바로 위에 코드랑 완전히 동일하게 만들어준다.
물론, JPQL은 JPA가 SQL로 번역해서 실행된다. 이건 당연한 이야기다.
위와 같이 메서드 시그니처만 만들어두면 되는데 이것도 규칙이라는 게 있다.
조회: findBy, readBy, queryBy, getBy 와 같은 키워드를 사용해야 한다.
물론 위와 같이 메서드 시그니처만 만들어도 알아서 뚝딱 뚝딱 만들어주는데 가끔은 그게 불편할때가 있다. 조건이 너무 많아서 메서드 이름이 너무 길어지는 경우가 딱 이 경우이다. 그럴땐 JPQL을 직접 작성할 수 있도록 해준다.
public interface SpringDataJpaItemRepository extends JpaRepository<Item, Long> {
//쿼리 메서드 기능
List<Item> findByItemNameLike(String itemName);
//쿼리 직접 실행
@Query("select i from Item i where i.itemName like :itemName and i.price <= :price")
List<Item> findItems(@Param("itemName") String itemName, @Param("price") Integer price);
}
위 코드와 같이 @Query 애노테이션을 사용해서 직접 JPQL을 작성하면 이 메서드를 실행하면 작성한JPQL대로 쿼리를 날려준다.
참고로, 스프링 데이터 JPA는 JPQL 뿐만 아니라, JPA의 네이티브 쿼리도 지원해준다. 그러니까 JPQL말고 SQL을 직접 작성해서 실행하게도 해준다.
package hello.itemservice.repository.jpa;
import hello.itemservice.domain.Item;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.Query;
import org.springframework.data.repository.query.Param;
import java.util.List;
public interface SpringDataJpaItemRepository extends JpaRepository<Item, Long> {
List<Item> findByItemNameLike(String itemName);
List<Item> findByPriceLessThanEqual(Integer price);
@Query("SELECT i FROM Item i WHERE i.itemName LIKE :itemName AND i.price <= :price")
List<Item> findItems(@Param("itemName") String itemName, @Param("price") Integer price);
}
스프링 데이터 JPA가 제공하는 JpaRepository 인터페이스를 상속받으면 기본적인 CRUD 기능을 사용할 수 있다.
그런데 이름으로 검색하거나, 가격으로 검색하는 기능은 공통으로 제공할 수 있는 기능이 아니다. 따라서 쿼리 메서드 기능을 사용하거나 @Query 애노테이션을 사용해서 직접 쿼리를 실행하면 된다.
아쉽게도 스프링 데이터 JPA는 동적 쿼리에 약하다. 마치 JdbcTemplate처럼. 그래서 이후에 QueryDsl을 사용하여 이 부분을 깔끔하게 해결해 볼 생각이다.
스프링 데이터 JPA의 스프링 데이터 접근 예외 추상화 지원
참고로, 이렇게 스프링 데이터 JPA가 제공하는 JpaRepository 인터페이스를 상속받으면 구현체도 프록시로 자동으로 만들어 준다고 했는데 그때, 스프링 예외 추상화를 지원한다. 즉, 스프링 데이터 JPA가 만들어주는 프록시에서 이미 예외 변환을 처리해서 구현체로 빈을 등록해주기 때문에 @Repository 애노테이션이 굳이 없어도 예외가 발생 시 스프링 데이터 접근 예외가 반환된다.
스프링 데이터 접근 예외 추상화는 스프링에서 제공해주는 기능이다. 결국 JPA를 사용하던, JDBC 기술을 직접 사용하던, 결국은 내부에서 JDBC 기술을 사용해서 데이터베이스와 연동한다. 그 과정에서 에러가 발생하면 SQLException이 발생하는데, 이 예외를 스프링은 추상화하여 예외 계층을 지원해준다. 그 부분에 대한 얘기인데, 이 내용은 다음 포스팅에 자세히 작성해 두었다.
JdbcTemplate과 한가지 다른 점은 MyBatis는 스프링 부트가 공식적으로 지원하는 라이브러리가 아니다. 그래서 현재 사용중인 스프링의 버전과 가장 적합한 버전을 찾아주지 않기 때문에 버전 명시가 필요하다.
이렇게 라이브러리를 다운받으면 다음과 같이 외부 라이브러리 리스트에 Mybatis가 노출된다.
근데 한가지 눈이 가는 부분이 있다. 빨간 표시해둔 `ibatis`? 이건 뭐지?
예전 이름이 ibatis고 지금은 mybatis로 변경된 것이다.
그 이름이 그대로 남아있을 뿐이고 그냥 mybatis라고 생각하면 된다.
그리고 라이브러리 보면, spring-boot-starter라는 이름과 autoconfigure 라는 이름의 라이브러리도 들어와 있는데 이거 친숙하다. 스프링 부트가 라이브러리 만들어낼 때 이런 이름을 사용하는데 mybatis는 스프링 부트에서 공식적으로 지원하는 라이브러리는 아니다. 근데 이름이 왜 이럴까? mybatis에서 직접 만든 라이브러리다. 스프링 부트와 사용할 때 사용자들에게 편리하게 설정을 해주도록 mybatis에서 직접 만들어서 넣어준 라이브러리다.
mybatis를 사용하려면 간단한 설정을 해줘야 한다. 이건 필수는 아니고 설정하면 편하다.
우선, type-aliases-package는 mybatis를 사용할 때 SELECT절로 가져오는 데이터를 객체로 바인딩할 때 어디에 있는 객체를 나타내는지 등을 작성하는 속성이다. 진행하면서 한번 더 이 부분에 대해 설명하겠다.
configuration.map-underscore-to-camel-case는 데이터베이스에서는 관례가 (_)를 사용하다 보니, 객체와 매핑할 때 alias를 사용해야 하는 불편함이 있다. 객체는 item_name 이 아니라 itemName으로 표기하니까. 그래서 SELECT절에서도 이렇게 사용해야 했다.
`select item_name as itemName`
그리고 객체로 매핑할 때 해당 필드를 찾아서 값을 넣어주는 방식으로 진행됐는데, 이렇게 configuration.map-underscore-to-camel-case 속성을 true로 설정해주면 자동으로 (_)를 camelCase로 변환해준다.
MyBatis는@Mapper라는 애노테이션이 필요한데, 이를 붙여야만 Mybatis 스프링 연동 모듈(아까 위에서 봤던 autoconfigure 라이브러리)이 스프링이 시작할 때 이 @Mapper가 있는 곳을 다 찾아서 인터페이스의 구현체를 내가 만든 xml 파일을 바라보며 직접 만들어주기 때문이다.
그리고 어떤건 @Param이 있고 어떤건 없는데, 이는 두 개 이상인 경우 @Param을 붙여야한다.
ItemMapper.xml
이제 실제 위 인터페이스의 구현체를 만들어야 하는데 그건 자바 파일로 만드는게 아니고 xml 파일로 만들어야 한다.
그리고 이 xml 파일의 경로는 임의로 정할수 있는게 아니고 반드시 인터페이스와 같은 패키지 경로와 일치해야한다. (물론 변경할 순 있다)
그래서 위 ItemMapper 인터페이스의 패키지 경로인 hello.itemservice.repository.mybatis를 src/main/resources 하위에 만들고 ItemMapper.xml 파일을 만들자.
save() 메소드와 매핑될 SQL문이다. useGeneratedKeys 속성은 데이터베이스가 키를 자동으로 생성해주는 IDENTITY 전략일 때 사용한다. 이 값을 true로 했으면 keyProperty를 설정해야 한다. keyProperty는 기본키의 컬럼명이다.
이제 파라미터를 넘겨받을 땐 `#{}` 문법을 사용한다. 이 안에 던질 데이터를 넣어주면 된다. save(Item item) 메소드의 이 item이 가지는 필드명이다. save(Item item) 메소드는 파라미터가 하나이기 때문에 바로 그 안에 필드에 접근할 수 있다. 그래서 #{item.itemName}이 아니고 #{itemName}으로 작성하면 된다.
<update id="update">
update item
set item_name=#{updateParam.itemName},
price=#{updateParam.price},
quantity=#{updateParam.quantity}
where id = #{id}
</update>
진짜 보기 편하게 생겼다. SQL문이 바로바로 보인다. 자 이제 update()를 보면 간단하다. 그냥 UPDATE 쿼리문을 작성하면 된다. 그리고 이 update() 메소드는 파라미터가 두개였기 때문에 @Param() 애노테이션에 괄호안에 작성한 값으로 파라미터를 바인딩해야 한다.
<select id="findById" resultType="Item">
select id, item_name, price, quantity
from item
where id = #{id}
</select>
이제 SELECT문이다. 이 또한 보기가 너무 좋긴 하다. 더 말할게 없다. resultType은 이 SELECT문이 반환하는 객체 타입을 작성해주면 된다. "Item"이다. 원래는 이것도 풀 패키지 명을 작성해줘야 하는데 위에서 작성한 application.yaml 파일을 기억하는가? type-alias-package를 작성해줬기 때문에 그 하위에 있는 Item을 찾게 된다.
이제 JdbcTemplate에서 느꼈던 단점인 동적 쿼리를 이 MyBatis가 어떻게 해결해주는지 확인해보자.
<select id="findAll" resultType="Item">
select id, item_name, price, quantity
from item
<where>
<if test="itemName != null and itemName != ''">
and item_name like concat('%', #{itemName}, '%')
</if>
<if test="maxPrice != null">
and price <= #{maxPrice}
</if>
</where>
</select>
너무 간단하다. 작성하는 코드도 몇 줄 안된다. 다른건 볼 것 없고 <where></where> 여기만 보면 되는데, 일단 <where> 태그가 마법같은 일들을 3개나 해준다.
안에 <if> 태그의 조건이 만족하는 게 없으면 WHERE절을 무시해버린다.
안에 <if> 태그의 조건이 하나라도 만족하면 WHERE절을 만들어준다.
WHERE절의 첫번째로 들어오는 문장에 "AND"가 있으면 지워준다.
이 세 조건을 딱 보고 <where> 태그를 보면 모든게 다 이해가 될 것인데 다만 한가지 아쉬운 점은 xml파일이기 때문에 <, > 기호가 그대로 태그로 인식이 된다. 이 문제를 해결하려면 이 기호를 <로 변환해줘야 한다.
ItemRepository 구현체
package hello.itemservice.repository.mybatis;
import hello.itemservice.domain.Item;
import hello.itemservice.repository.ItemRepository;
import hello.itemservice.repository.ItemSearchCond;
import hello.itemservice.repository.ItemUpdateDto;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;
import java.util.List;
import java.util.Optional;
@Repository
@RequiredArgsConstructor
public class MyBatisItemRepository implements ItemRepository {
private final ItemMapper itemMapper;
@Override
public Item save(Item item) {
itemMapper.save(item);
return item;
}
@Override
public void update(Long itemId, ItemUpdateDto updateParam) {
itemMapper.update(itemId, updateParam);
}
@Override
public Optional<Item> findById(Long id) {
return itemMapper.findById(id);
}
@Override
public List<Item> findAll(ItemSearchCond cond) {
return itemMapper.findAll(cond);
}
}
여기서는 ItemRepository 구현체는 ItemMapper의 메소드를 가지고 위임만 해준다.
DTO
ItemSearchCond.java
package hello.itemservice.repository;
import lombok.Data;
@Data
public class ItemSearchCond {
private String itemName;
private Integer maxPrice;
public ItemSearchCond() {
}
public ItemSearchCond(String itemName, Integer maxPrice) {
this.itemName = itemName;
this.maxPrice = maxPrice;
}
}
