[JPA] OSIV 찍먹하기 1편 - 프록시 객체와 준영속 상태 엔티티

금요일에 근로하면서 구구와 근로 크루들의 도움 덕분에 JPA를 다시금 공부하게 됐다 😅

나도 완전하게 잘 아는 내용은 아닌지라 아는대로 정리해보고자 한다.

 

---

 

🌱 영속성 컨텍스트와 트랜잭션

💡 영속성 컨텍스트란?
엔티티를 영속화시키는 환경. EntityManager를 통해 엔티티를 저장하거나 조회하면 영속성 컨텍스트에 보관된 엔티티 정보를 바탕으로 요청을 처리하게 된다. EntityManager 생성 시 1개가 만들어진다.

💬 특징
- 식별자 값으로 엔티티를 구분한다.
- 트랜잭션 커밋 시점에 flush. (쓰기 지연 - 내부 쿼리 저장소에 SQL 저장 후 한 번에 플러시)
- 1차 캐시를 사용한다. (처음에 1차 캐시에서 엔티티 조회 > 없으면 DB 조회 > 1차 캐시에 저장하는 형태 = '영속화')
- 1차 캐시에 저장된 엔티티는 == 비교가 가능하다. (동일성 보장)
- 변경 감지 ('영속 상태의' 변경된 엔티티에 대해서 업데이트 쿼리 저장 > 플러시 > 트랜잭션 커밋)

트랜잭션이 시작되면 영속성 컨텍스트도 생성되고, 종료되면 컨텍스트도 함께 종료되는 것이다.

그리고, 동일한 트랜잭션 안에서는 항상 같은 영속성 컨텍스트에 접근하게 된다.

 

여기서 말하는 트랜잭션은 우리가 스프링을 개발하면서 사용한 @Transactional 어노테이션의 범위를 의미한다.

@Transactional이 붙어있으면 해당 메서드를 호출하기 전에 트랜잭션 AOP가 먼저 동작하는데 (이에 대해서는 추후 다루어 보겠다.) 간단하게 생각하면 해당 메서드를 호출하기 전에 트랜잭션을 시작하고, 정상적으로 종료되면 트랜잭션 커밋 후 종료하는 것이다.

 

이때, JPA에서는 영속성 컨텍스트를 플러시하여 변경 사항을 DB에 반영한 뒤, DB 트랜잭션을 커밋하게 된다.

흔히 우리는 관습적으로 개발할 때 @Transactional 어노테이션을 서비스 레이어에 붙이곤 한다.

그렇기 때문에 서비스 계층이 끝나는 시점에 트랜잭션이 종료되며 영속성 컨텍스트도 함께 종료되어, 서비스와 레파지토리 레이어에서는 영속 상태인 엔티티가 컨트롤러나 뷰 같은 presentation layer에서는 준영속 상태가 된다.

 

그래서 컨트롤러나 뷰 (혹은 DTO)에서 준영속 상태인 엔티티를 통해 지연 로딩을 시도하면 예외가 발생한다.

 

💡 지연 로딩 (Lazy Loading)이란?
- 엔티티를 조회할 때 연관된 엔티티에 대해 실제 DB에서 바로 접근하지 않고, 연관된 엔티티를 실제로 사용하는 시점에 로딩하는 방법. 지연 로딩을 사용하기 위해서는 실제 엔티티 객체 대신에 데이터베이스 조회를 지연할 수 있는 가짜 객체가 필요하며, 이를 위해 프록시 객체를 사용한다.
- OneToMany, ManyToMany에서 디폴트로 사용하는 전략이다.

 

하지만, 스프링 부트를 활용하여 개발할 때는 다르다.

처음 스프링부트 애플리케이션을 활성화시키면 아래와 같은 문구가 뜨는 것을 볼 수 있을 것이다.

spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning

기본적으로 스프링부트는 OSIV를 활성화하기 때문에 view rendering 시점까지 DB 쿼리의 영향을 받을 수 있다는 것이다.

이론만 보면 당연히 이해하기 힘들다. 간단한 클래스를 구성하여 직접 살펴보자.

(OSIV에 대해서는 다음 포스팅에서 더 자세히 다룰 예정이다.)

 

---

 

🌱 프록시 객체

JPA를 생각하면 뺄 수 없는 개념 중 하나가 프록시 객체이다.

코드를 보기 전에 간단하게 프록시 객체가 어떤 것인지 짚고 넘어가보자.

 

JPA에서 엔티티를 하나 조회할 때는 EntityManager.find()라는 메서드를 사용하는데, 이는 영속성 컨텍스트에 엔티티가 없으면 실제 DB를 조회하는 메서드이다. 하지만, 이런 식으로 직접 조회하게 되면 해당 엔티티의 사용 여부와 관계없이 무조건 DB를 조회하기 때문에 cost가 매우 높다. 만약 DB 조회를 실제 사용 시점까지 미루고 싶다면 EntityManager.getReference()를 사용하게 된다.

이는 DB 조회 대신에 이를 대체할 프록시 객체를 생성하게 된다.

이러한 프록시 객체를 생성하기 위해서는 '상속'을 사용하기 때문에 기본 생성자가 필요하다.

생성자가 아예 없는 상황이라면 컴파일러가 알아서 만들어주지만, 하나라도 다른 생성자가 있으면 만들어주지 않기 때문에 기본 생성자는 웬만하면 만들어줘야 한다.

 

프록시 객체는 실제 객체에 대한 참조값을 가지고 있다가, 프록시 객체의 메서드를 호출하면 실제 객체의 메서드를 호출해준다.

위의 상황에서 프록시 객체는 crew.getName()을 통해 직접 접근하게 되면 실제 DB를 조회하여 실제 엔티티를 생성하게 되는데, 이를 '프록시 객체의 초기화'라고 한다.

 

1. 프록시 객체의 crew.getName()을 호출하여 실제 데이터 조회하기
2. 실제 엔티티가 생성되지 않았다면, 영속성 컨텍스트에게 실제 엔티티의 생성 요청
3. 영속성 컨텍스트는 DB를 조회하여 실제 엔티티 객체 생성
4. 프록시 객체는 생성된 엔티티 객체의 참조를 보관
5. 보관한 참조값(crew)의 getName()을 호출하여 결과 반환

이러한 프록시 객체는 처음 사용될 때 딱 한 번만 초기화된다.

또한, 영속성 컨텍스트에 이미 엔티티가 있으면 DB를 조회할 필요가 없기 때문에 em.getReference()를 호출해도 프록시 객체 대신 실제 엔티티를 반환하게 된다!

 

자세한 내용은 차차 JPA 공부하면서 올릴 예정! 😊

---

🌱 테이블 설계

✔️ Entity

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Wootecho {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Enumerated(EnumType.STRING)
    private Course course;
}

우테코 클래스이다. Course라는 enum에는 백엔드, 프론트, 안드로이드라는 과정 정보가 들어가있다.

 

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Crew {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String name;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "wootecho_id", nullable = false, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
    private Wootecho wootecho;
}

간단한 크루 클래스이다.

크루 클래스와 우테코 클래스는 N:1의 관계를 가지고 있으며, 이때 지연 로딩 전략을 채택하였다. (FetchType.LAZY)

또한, 외래키 제약 조건에 대한 설정을 지정해주지 않았다.

 

실제 테이블의 관계는 아래와 같이 맺어진다.

 

하지만, 이는 논리적인 연관관계일 뿐이며 실제로 테이블 스크립트를 보면 아래와 같이 외래키 제약조건이 설정되지 않은 것을 볼 수 있다.

CREATE TABLE `wootecho` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `course` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3

CREATE TABLE `crew` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `wootecho_id` bigint NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3

crew 테이블은 단순히 wootecho_id라는 필드를 가지고 있을 뿐이지, 외래키로 걸려있지 않다.

 

이는 다음과 같은 설정 때문이다.

@JoinColumn(... foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
private Wootecho wootecho;

여기서 foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT) 를 설정해주면, 물리적인 외래키를 맺지 않게 된다.

실제로 실무에서는 외래키를 걸지 않는 경우가 많다. 

외래키를 걸면 데이터의 무결성은 보장할 수 있지만 (부모가 삭제되었을 때 고아로 남은 자식 필드가 남지 않도록 함)

자식 테이블의 INSERT 연산 시에 부모 테이블도 확인해야 하고, 변경 시에도 고려해야 할 점이 많고, 테스트하기도 어렵기 때문이다.

 

영한님은 이에 대해서 아래와 같이 답변을 남겨주신 적이 있다.

나 역시 개인적으로 외래키를 거는 걸 선호하지만... 아마 작은 도메인만 만져봤기 때문일 것 같다 😅

아무튼, 이게 중요한 것은 아니다. 도메인을 위와 같이 설계했고, 레파지토리와 서비스, 컨트롤러는 다음과 같다.

 

 

✔️ Repository

public interface CrewRepository extends JpaRepository<Crew, Long> {

}

흔히 사용하는 Jpa를 사용한 레파지토리 구성이다.

 

 

✔️ Service

@Service
@Transactional(readOnly = true)
@AllArgsConstructor
public class CrewService {

    private final CrewRepository crewRepository;

    public Crew getById(final Long wootechoId) {
        final Crew findCrew = crewRepository.findById(wootechoId)
            .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 아이디입니다."));
        return findCrew;
    }
}

서비스에서는 단순히 아이디를 통해 크루 엔티티를 조회해오는 로직만 있다.

 

 

✔️ Controller

@RestController
@RequestMapping("/crew")
@AllArgsConstructor
public class CrewController {

    private final CrewService crewService;

    @GetMapping("/{crewId}")
    public ResponseEntity<CrewResponse> getById(@PathVariable Long crewId) {
        final Crew crew = crewService.getById(crewId);
        return ResponseEntity.ok(CrewResponse.of(crew));
    }
}

컨트롤러이다. 여기서 주목할 점은 서비스에서 엔티티를 받아와서 dto로 변환하는 로직을 이곳에서 한다는 것이다.

 

 

✔️ Dto

@Getter
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class WootechoResponse {
    private final Long id;
    private final String course;

    public static WootechoResponse of(final Wootecho wootecho) {
        return new WootechoResponse(wootecho.getId(), wootecho.getCourse().name());
    }
}

@Getter
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class CrewResponse {

    private final Long id;
    private final String name;
    private final WootechoResponse wootechoResponse;

    public static CrewResponse of(final Crew crew) {
        return new CrewResponse(crew.getId(), crew.getName(), WootechoResponse.of(crew.getWootecho()));
    }
}

크루에 대한 응답 정보를 나타내기 위해서 crew 엔티티에 있는 값들과 연관된 엔티티인 wootecho 엔티티를 가져오고 있다.

정말 간단한 조회용 API가 완성되었다.

 

현재 도메인 구조는 이렇게 구성되어 있다.

 

 

---

🌱 준영속 상태와 지연 로딩

준영속 상태에서는 지연 로딩이 동작하지 않는다.

💡 준영속 상태 엔티티란?
영속성 컨텍스트가 관리하던 영속 상태인 엔티티가 더 이상 영속성 컨텍스트에 의해 관리되지 않는 상태

지연 로딩을 사용하기 위해서는 프록시 객체를 설정해주고, 엔티티 조회 시 연관된 엔티티에 대해 프록시 객체를 조회한다.

하지만, 준영속 상태인 엔티티는 영속성 컨텍스트가 없기 때문에 지연 로딩 자체가 불가능해진다.

이를 실제로 확인해보자.

우선, 앞서 말했던 것처럼 스프링부트는 기본적으로 뷰까지 DB 쿼리가 날라가는 것을 허용하기 때문에 이 옵션을 꺼야 한다.

 

spring:
  jpa:
    open-in-view: false

application.yml에서 open-in-view 옵션을 false로 설정해준다.

 

그리고, 크루 1명을 조회하는 API 요청을 날려보자. 나는 '져니'라는 크루를 조회할 예정이다.

could not initialize proxy [com.example.study.osiv.Wootecho#1] - no Session

세션이 없기 때문에 proxy를 초기화할 수 없다고 나온다.

지연 로딩을 하기 위해서는 연관된 엔티티를 '프록시 객체'로서 만들어두고, 사용 시점에 쿼리를 날린다고 말했었다.

// CrewResponse.java
public static CrewResponse of(final Crew crew) {
    return new CrewResponse(crew.getId(), crew.getName(), WootechoResponse.of(crew.getWootecho()));
}

CrewResponse의 코드이다. 여기서 crew.getWootecho()를 통해 조회를 할 때에는 담겨있던 프록시 객체를 호출하게 된다.

실제로 보면, HibernateProxy라는 친구를 통해서 프록시 객체를 가져온 것을 볼 수 있다.

 

// WootechoResponse.java
public static WootechoResponse of(final Wootecho wootecho) {
    return new WootechoResponse(wootecho.getId(), wootecho.getCourse().name());
}

그리고, WootechoResponse에서 실제로 값을 채워넣으려고 할 때 프록시 객체를 초기화하면서 실제 값을 채워넣으려고 하자 오류가 발생한 것이다.

 

dto 변환을 controller = presentation layer에서 하면서, 그림과 같이 서비스 레이어를 지나 트랜잭션 범위가 끝나면서 영속성 컨텍스트도 함께 제거되었기 때문이다. no session이라는 것이 곧 EntityManager가 없어서 값을 가져올 수가 없던 것이다.

 

service 레이어에서 조회해온 Crew 엔티티는 '영속 상태'였으나, controller 레이어로 넘어오면서 영속성 컨텍스트가 제거되어 Crew 엔티티는 준영속 상태의 엔티티가 되었다.

 

사실 가장 좋은 방법은 컨트롤러에서 반환하지 않고, 그냥 서비스에서 DTO를 반환하도록 코드를 개선하는 것이다.

// CrewService.java
public CrewResponse getById(final Long wootechoId) {
    final Crew findCrew = crewRepository.findById(wootechoId)
        .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 아이디입니다."));
    return CrewResponse.of(findCrew);
}

이렇게 되면 영속성 컨텍스트 범위가 살아있는 범위에서 프록시 객체 초기화가 가능하기 때문에 걱정할 필요가 없다.

 

하지만, 우리는 컨트롤러에서 엔티티를 dto로 변환하는 작업은 할 수 없는 것일까?

다음 포스팅에서 어떻게 하면 이를 개선할 수 있을지 살펴보자.