[JPA] OSIV(Open Session In View)란?

🤔 OSIV에 대해 알아보기 전.. Persistence Context 를 모른다면?

[JPA] 영속성 컨텍스트의 동작원리와 이점

---

🤧 OSIV 요약

특징

• OSIV는 클라이언트 요청이 들어올 때 영속성 컨텍스트를 생성해서 요청이 끝날 때까지 같은 영속성 컨텍스를 유지한다.
  따라서 한 번 조회된 엔티티는 요청이 끝날 때까지 영속 상태를 유지한다.
• 엔티티 수정은 트랜잭션이 있는 계층(서비스, 레포지토리 계층)에서만 동작한다. 트랜잭션이 없는 프레젠테이션 계층은 지연 로딩을 포함해 조회만 할 수 있다.

단점

• 영속성 컨텍스트와 DB 커넥션은 1:1로 물고있는 관계이기 때문에 프레젠테이션 로직까지 DB 커넥션 자원을 낭비하게 된다.
• OSIV를 적용하면 같은 영속성 컨텍스트를 여러 트랜잭션이 공유하게될 수도 있다.
• 프레젠테이션에서 엔티티를 수정하고 비즈니스 로직을 수행하면 엔티티가 수정될 수 있다.
• 프레젠테이션 계층에서 렌더링 과정에서 지연 로딩에 의해 SQL이 실행된다.
  따라서 성능 튜닝시에 확인해야 할 부분이 넓어진다.

---

스프링은 기본으로 트랜잭션 범위의 영속성 컨텍스트 전략을 사용한다.

 

• 비영속
  • 영속성 컨텍스트와 전혀 관계가 없는 새로운 상태
  • 객체를 생성만 한 상태
• 영속
  • 영속성 컨텍스트에 관리되는 상태
  • 객체 생성 후 em.persist(member)로 저장한 상태
• 준영속
  • 영속성 컨텍스트에 저장되었다가 분리된 상태
  • em.detach(member)로 영속이 분리된 상태
• 삭제
  • 삭제된 상태
  • em.remove(member)로 영구 저장한 데이터베이스를 지우는 상태

🤔 비영속과 준영속 상태의 차이점이 뭘까?

 

둘의 가장 큰 차이는 한번 영속 상태가 된 적이 있는가 없는가의 차이

영속 상태가 되려면 식별자가 반드시 존재해야하기 때문에 영속 상태가 되었다가 다시 준영속 상태가 되면 식별자가 항상 존재한다.

ex) 엔티티 조회 후 트랜잭션이 끝나 영속성 컨텍스트가 사라지는 경우 조회한 엔티티가 준영속 상태가 됨

 

트랜잭션은 보통 서비스 계층에서 시작되기 때문에 서비스 계층이 끝나는 시점에 트랙잭션이 종료되어 영속성 컨텍스트도 종료된다.

트랜잭션 커밋 시 JPA는 영속성 컨텍스트를 먼저 flush 해 변경 내용을 DB에 반영한 후 DB 트랜잭션을 커밋한다.

(예외가 발생해 트랜잭션이 롤백 후 종료될 경우 flush 호출 X)

따라서 트랜잭션이 없는 프레젠테이션 계층(Controller)에서 조회한 엔티티는 준영속 상태가 된다.

→ 준영속 상태가 될 경우 변경 감지와 지연 로딩이 동작하지 않는다.

😉 변경 감지가 안되면 어떤 일이 벌어지나요?

보통 변경 감지 기능은 서비스 계층에서 비즈니스 로직을 수행하면서 발생하고

단순히 데이터를 보여주는 용도인 프레젠테이션 계층에서 데이터를 수정할 일은 거의 없기 때문에 큰 문제가 되지는 않는다.

 

🥹 지연 로딩은..?

준영속 상태에서 지연 로딩이 동작하지 않는 것은 문제가 된다..

예를들어 프레젠테이션 계층에서 연관된 엔티티도 함께 사용해야 되는데 해당 엔티티를 지연 로딩으로 설정했을 경우 LazyInitializationException 예외가 발생한다.

 

 

@Entity
public class ReviewImage {

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

    private String imageUrl;

    @ManyToOne(fetch = FetchType.LAZY)	// 지연 로딩
    private Review review;
    
}

위와 같이 리뷰 이미지 엔티티에서 리뷰 엔티티를 지연 로딩으로 설정할 경우 아직 초기화하지 않은 프록시 객체를 조회하기 때문에 컨트롤러나 뷰의 지연 로딩 시점에서 예외가 발생한다.

class ReviewController {

	public String view(Long reviewId) {
   	    Review review = reviewService.findOne(reviewId);
   	    ReviewImage reviewImage = review.getReview();
   	    reviewImage.getImageUrl();	// 지연 로딩 시 예외 발생
    }
}

 

---

준영속 상태에서 지연 로딩 문제를 해결하는 방법

👍 뷰가 필요한 엔티티 미리 로딩해두기

1️⃣ 글로벌 페치 전략을 즉시 로딩으로 수정

@Entity
public class ReviewImage {

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

    private String imageUrl;

    @ManyToOne(fetch = FetchType.EAGER)	// 즉시 로딩 전략
    private Review review;
    
}

애플리케이션 전체에서 엔티티를 로딩할 때마다 해당 엔티티의 fetch 타입으로 지정한 전략을 사용하므로 글로벌 페치 전략이라 한다.

글로벌 페치 전략을 FetchType.EAGER로 설정하고 ReviewImage 엔티티 조회 시 연관된 review 엔티티도 항상 함께 로딩한다. 따라서 준영속 상태가 되어도 review를 사용할 수 있다.

 

하지만 이렇게 즉시 로딩으로 글로벌 페치 전략을 사용 시 사용하지 않는 엔티티를 항상 로딩해오는 문제와 N+1 문제가 발생한다.

🤧 N+1 문제란?

select p.*, m.*
from Post p
left outer join Member m on p.MEMBER_ID=m.MEMBER_ID
where p.id=1

em.find로 post 엔티티 조회 시 즉시 로딩으로 설정한 member 엔티티를 JOIN 쿼리로 함께 조회한다.

이를 JPQL로 조회 시

List<Post> posts = em.createQuery("select p from Post p", Post.class)
	.getResultList();	// 연관된 모든 엔티티 조회

 실행되는 SQL은 아래와 같다.

select * from Post	# JPQL로 실행된 SQL
select * from Member where id=?	# EAGER로 실행된 SQL
select * from Member where id=?	# EAGER로 실행된 SQL
select * from Member where id=?	# EAGER로 실행된 SQL
select * from Member where id=?	# EAGER로 실행된 SQL

 JPA가 JPQL을 분석해 SQL을 생성할 때는 글로벌 페치 전략을 참고하지 않고 JPQL 자체만 사용하기 때문에 즉시 로딩이든 지연 로딩이든 상관없이 SQL을 만든다.
만약 조회한 post 엔티티가 20개이면 member를 조회하는 SQL도 20번 실행되는 것이다. 이를 N+1 문제라 한다.

 

 

 

글로벌 페치 전략을 즉시 로딩으로 설정하면 애플리케이션 전체에 영향을 주므로 비효율적이다.

 

2️⃣ JPQL 페치 조인

페치 조인 사용 시 JPQL을 호출하는 시점에 함께 로딩할 엔티티를 선택할 수 있다.

페치 조인을 사용하면 SQL JOIN을 사용해 페치 조인 대상까지 함께 조회하기 때문에 N+1 문제가 발생하지 않는다.

# JPQL
SELECT p FROM Post p JOIN FETCH p.member

# SQL
SELECT p.*, m.*
FROM Post p
JOIN Member m on p.MEMBER_ID=m.MEMBER_ID

 

하지만 페치 조인을 무분별하게 사용하면 화면에 맞춘 레포지토리 메서드가 증가할 수 있기 때문에 적절한 선에서 타협점을 찾는 것이 합리적이다.

 

3️⃣ 강제 초기화

강제 초기화는 영속성 컨텍스트가 살아있을 때 프레젠테이션 계층이 필요한 엔티티를 강제로 초기화해서 반환하는 방법이다.

class ReviewService {

    @Transactional
    public Review findReview(id) {
    	Review review = reviewRepository.findReview(id);
        review.getReviewImage().getUrl();	// 프록시 객체 강제 초기화
        return review;
    }
}

글로벌 페치 전략을 지연 로딩으로 설정 시 연관된 엔티티는 실제 엔티티가 아닌 프록시 객체로 조회되며, 프록시 객체는 실제 사용하는 시점에 초기화된다.

따라서 위처럼 프레젠테이션 계층에서 필요한 프록시 객체를 서비스 계층에서 영속성 컨텍스트가 살아 있을 때 강제로 초기화해 반환하면 이미 초기화했기 때문에 준영속 상태에서 초기화할 수 있다.

 

하지만 프록시를 초기화하는 역할을 서비스 계층이 담당하면 뷰가 필요한 엔티티에 따라 서비스 계층의 로직을 변경해야 되기 때문에 프레젠테이션 계층이 서비스 계층을 침범하는 상황이 발생한다.

따라서 서비스 계층에서 프레젠테이션 계층을 위한 프록시 초기화 역할을 분리하는 FACADE 계층을 추가해 위 문제를 해결할 수 있다.

 

뷰를 위한 프록시 초기화를 FACADE 계층에서 담당해 서비스 계층과 프레젠테이션 계층 사이 논리적 의존성을 분리할 수 있지만 실용적인 관점에서 볼 때 중간에 계층이 하나 더 끼어 결국 더 많은 코드를 작성해야 되는 단점이 있다.

 

✌️ OSIV를 사용해 엔티티를 항상 영속 상태로 유지하기

아까 트랜잭션이 없는 프레젠테이션 계층(Controller)에서 조회한 엔티티는 준영속 상태가 된다는 말을 더 깊게 파고들어보자

 

OSIV는 요청이 처리되는 동안 영속성 컨텍스트를 열어두고 트랜잭션 범위를 넘어선 레이어까지 연관된 엔티티를 로딩할 수 있도록 한다.

OSIV가 trueAPI일 경우 클라이언트에게 응답될 때까지, View일 경우 View가 렌더링될때까지 영속성 컨텍스트가 살아있다.

🌱 비즈니스 계층에서 트랜잭션을 사용하는 OSIV의 동작 원리 🌱

1. 클라이언트의 요청이 들어오면 서블릿 필터나, 스프링 인터셉터에서 영속성 컨텍스트를 생성    단, 트랜잭션은 시작하지 않음
2. 서비스 계층에서 @Transactional로 트랜잭션을 시작할 때 1번에서 미리 생성해둔 영속성 컨텍스트를 찾아와 트랜잭션 시작
3. 서비스 계층이 끝나면 트래잭션 commit, 영속성 컨텍스트 flush
    이때 트랜잭션은 끝내지만 영속성 컨텍스트는 종료하지 않음
4. 컨트롤러와 뷰까지 영속성 컨텍스트가 유지되므로 조회한 엔티티는 영속 상태 유지중
5. 서블릿 필터나, 스프링 인터셉터로 요청이 돌아오면 영속성 컨텍스트 종료.
     이때 flush를 호출하지 않고 바로 종료

❄️ 트랜잭션과 영속성 컨텍스트
- 영속성 컨텍스트는 트랜잭션 범위 안에서 엔티티를 조회하고 수정할 수 있다.
- 영속성 컨텍스트는 트랜잭션 범위 밖에서 엔티티를 조회만 할 수 있다. (트랜잭션 없이 읽기: Nontransactional reads)

❄️ 스프링이 제공하는 OSIV 특징
- 영속성 컨텍스트를 프레젠테이션 계층까지 유지한다.
- 프레젠테이션 계층은 트랜잭션이 없기 때문에 엔티티를 수정할 수 없다.
- 프레젠테이션 계층에서 트랜잭션 없이 읽기를 사용해 지연 로딩을 할 수 있다.(프록시 객체 초기화 가능)
     - 엔티티가 준영속 상태여서 발생하는 문제 해결
- OSIV가 켜져있으면 요청 당 엔티티 매니저는 한 번 생성되고, 뷰 렌더링이 끝날 때까지 엔티티 매니저는 종료되지 않음
   또한 트랜잭션이 다르더라도 1차 캐시 공유

 

만약 트랜잭션 범위 밖인 컨트롤러와 뷰에서 엔티티를 수정해도 영속성 컨텍스트의 변경 감지에 의한 데이터 수정이 다음 두가지 이유로 동작하지 않는다.

• 영속성 컨텍스트의 변경 내용을 DB에 반영하려면 영속성 컨텍스트를 flush 해야 한다. 스프링이 제공하는 OSIV는 요청이 끝나면 flush를 호출하지 않고 em.close()로 영속성 컨텍스트만 종료시켜 버린다.
• 프레젠테이션 계층에서 em.flush()를 호출하여 강제로 flush 해도 트랜잭션 범위 밖이므로 데이터를 수정할 수 없다는 예외가 일어난다.   → javax.persistence.TransactionRequiredException

 

🤔 트랜잭션이 끝나도 connection이 반납되지 않는다고?

JPA의 open-in-view 설정이 true일 경우 api의 요청부터 응답까지 영속성 컨텍스트가 유지된다.

스프링 부트에서는 open-in-view 속성의 default 값이 true이기 때문에 트랜잭션이 끝나도 DB connection이 반납되지 않는 것이다.

 

🤩 OSIV 사용시 주의점

 

설정을 아무것도 건드리지 않고 기본값으로 애플리케이션을 구동하면 애플리케이션 시작 시 위에서 보이는 WARN 로그가 뜬다.

위에서 설명했듯이 프록시를 초기화하는 작업을 Service 계층에서 끝내지 않고 렌더링 시 자동으로 해결되는 OSIV 전략에 경고를 주는 이유가 뭘까?

 

OSIV 전략은 너무 오랜시간 DB connection 자원을 사용하기 때문에, 실시간 트래픽이 중요한 애플리케이션에서는 커넥션이 모자랄 수 있고 이것은 장애로 이어지게 된다.

예를 들어 컨트롤러에서 외부 API 호출 시 외부 API 대기 시간만큼 커넥션 자원을 반환하지 못하고, 유지해야 한다.

→ OISV의 치명적인 단점인, 커넥션을 영속성 컨텍스트가 종료될 때까지 1:1로 계속 물고 있는 것이다.

🤔 open-in-view 설정을 수정하면 어떻게 되는거야?

open-in-view를 false로 설정할 경우 트랜잭션이 끝나고 DB connection이 반납되지 않던 문제는 해결된다.

하지만 lazy loading을 사용할 경우 문제가 발생할 수 있다. 지금까지 작성한 많은 지연 로딩 코드를 트랜잭션 안으로 넣어야 하는 것이다.

 

EntityManager가 트랜잭션의 커밋과 함께 닫혀 트랜잭션 외부에서 lazy loading을 사용하면 no Session 이라는 예외가 발생하게 된다.

이는 요청부터 응답까지를 하나의 트랜잭션으로 묶는 방법으로 해결할 수 있지만 이는 open-in-view를 true로 설정하는 것과 비슷하다.

 

🤧 Command와 Query 분리

실무에서 OSIV를 끈 상태로 복잡성을 관리하는 좋은 방법은 Command와 Query를 분리하는 것이라고 한다.

 

보통의 비즈니스 로직은 특정 엔티티 몇 개를 등록하거나 수정하는 것이기 때문에 성능이 크게 문제되지 않는다.

그러나 복잡한 화면을 출력하기 위한 쿼리는 화면에 맞추어 성능을 최적화 하는 것이 중요하다.

하지만 그런 동작은 복잡성에 비해 핵심 비즈니스에 큰 영향을 주는 것은 아니다.

 

따라서 크고 복잡한 애플리케이션을 개발한다면, 이 둘의 관심사를 명확하게 분리하는 선택이 유지보수의 관점에서 의미가 있을 것이다.

ex) OrderService

• OrderService: 핵심 비즈니스 로직
• OrderQueryService: 화면이나 API에 맞춘 서비스 (주로 읽기 전용 트랜잭션 사용)

두 서비스 모두 트랜잭션을 유지하면서 지연 로딩을 사용할 수 있다.

 

---

아래 글에서 엔티티 매니저가 생성되는 과정을 엄청 자세히 알 수 있다.

엔티티 매니저는 리퀘스트 당 하나만 생성되지 않을 수 있다.

(JPA) 엔티티 매니저는 리퀘스트 당 하나만 생성되지 않을 수 있다.

 

 

 

https://perfectacle.github.io/2021/05/24/entity-manager-lifecycle/

https://medium.com/frientrip/spring-boot%EC%9D%98-open-in-view-%EA%B7%B8-%EC%9C%84%ED%97%98%EC%84%B1%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC-83483a03e5dc

https://ykh6242.tistory.com/entry/JPA-OSIVOpen-Session-In-View%EC%99%80-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94

https://ykh6242.tistory.com/entry/JPA-OSIVOpen-Session-In-View%EC%99%80-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94