트랜잭션 범위의 영속성 컨텍스트

순수하게 J2SE 환경에서 JPA를 사용하면 개발자가 직접 엔티티매니저를 생성하고 트랜잭션도 관리해야한다. 하지만 스프링이나 J2EE 컨테이너 환경에서 JPA를 사용하면 컨테이너가 제공하는 전략을 따라야 한다.

스프링 컨테이너의 기본 전략

• 트랜잭션 범위의 영속성 컨텍스트 전략을 기본으로 사용
  • 트랜잭션의 범위와 영속성 컨텍스트의 생존 범위가 같다
  • 트랜잭션을 시작할 때 영속성 컨텍스트를 생성하고 끝날때 종료함
  • 같은 트랜잭션 안에서는 항상 같은 영속성 컨텍스트에 접근
• 스프링을 사용하면 보통 비즈니스 로직을 시작하는 서비스 계층에 @Transactional 어노테이션을 선언해 트랜잭션을 시작함
• 트랜잭션이 같으면 같은 영속성 컨텍스트를 사용하는 반면 같은 엔티티매니저를 사용하더라도 트랜잭션에 따라 접근하는 영속성 컨텍스트가 다르다.
  • 스레드마다 각각 다른 트랜잭션을 할당한다.
  • 따라서 thread-safe 하다.
  • 스프링의 가장 큰 장점은 복잡한 멀티 스레드 상황을 컨테이너가 처리해준다는 점이다.
  • 개발자는 싱글 스레드 어플리케이션처럼 개발할 수 있고 비즈니스로직에 집중할 수 있다.

준영속 상태와 지연로딩

• 서비스 계층이 끝나는 시점에 트랜잭션이 종료되면서 영속성 컨텍스트도 함께 종료된다.

• 트랜잭션이 없는 계층(프레젠테이션 계층)에서 기본적으로 엔티티는 준영속 상태이다.

• 따라서 변경감지와 지연 로딩이 동작하지 않는다.

  • 준영속 상태에서 지연로딩 문제를 해결하는 방법
    • 뷰가 필요한 entity를 미리 로딩해두는 방법
      • 글로벌 페치 전략 수정
        • 지연로딩 → 즉시로딩
          • 사용하지 않는 엔티티를 로딩한다
          • N+1(JPQL 사용시)
            • JPA가 JPQL을 분석해서 SQL을 생성할 때는 글로벌 페치 전략을 참고하지 않고 오직 JPQL 자체만 사용한다.
        • JPQL fetchJoin
          • 뷰와 레포지토리 간의 논리적인 의존관계가 발생할 수 있음
          • 무분별한 최적화로 프레젠테이션게층과 데이터 접근 게층 간의 의존관계가 급격하게 증가하는 것보다는 적절한 선에서 타협점을 찾는 것이 합리적임
        • 강제로 초기화
          • 영속성컨텍스트가 살아있을 때 프레젠테이션 계층이 필요한 엔티티를 강제로 초기화해서 반환하는 방법
          • getName() 등을 이용해 강제로 즉시로딩처럼 사용하는 방법
          • 뷰가 필요한 엔티티에 따라 서비스 계층의 로직을 변경해야 하기때문에 계층간 침범이 일어나게 됨
            • FACADE 계층 추가

              • 프레젠테이션 계층과 서비스 계층사이에 파사드 계층을 하나 더 두어 논리적인 의존성 분리

              • 뷰를 위한 프록시 초기화는 이곳에서 담당함

                

              • 프록시를 초기화하려면 영속성 컨텍스트가 필요하므로 FACADE에서 트랜잭션을 시작해야함

              • BUT 실용적인 관점에서 호출만하는 위임코드가 많아지는 오버헤드가 있을 수 있음

                

• 준영속 상태와 지연 로딩의 문제점

  • 미리 초기화하는 방식은 오류가 발생하기 쉬움 → 개발시에 FACADE나 서비스 클래스까지 열어보고 엔티티가 초기화되었는지 확인하는 것은 매우 번거로움
  • FACADE를 써서 논리적 연관성을 분리한다고 하면 번거로움
    • 화면별로 최적화된 엔티티를 딱딱 맞아떨어지게 초기화해서 조회하려면 FACADE에 엄청나게 많은 조회 메서드가 필요하게 될 것
  • 모든 문제는 프레젠테이션 계층에서 준영속 상태이기 때문에 발생 → 영속성컨텍스트를 살아있도록 두는것이 OSIV

OSIV

• Open Session in View(영속성 컨텍스트를 뷰까지 열어둔다는 뜻)

1. 요청당 트랜잭션

   • 프레젠테이션 계층이 엔티티를 변경할 수 있다는 단점

     

   • 엔티티를 수정하지 못하게 막자!

     • 엔티티를 읽기 전용 인터페이스로 제공

     interface MemberView {
     	public String getName();
     }
     
     @Entity
     class Member implements MemberView {
     }
     
     

     • 엔티티 래핑

     class MemberWrapper {
     
     private Member member;
     
     public MemberWrapper(member) { 
     	this.member = member;
     }
     
     //읽기 전용 메소드만 제공
     public String getName() {
     	member.getName();
     }
     

     • DTO만 반환 → OSIV를 사용하는 장점을 살릴 수 없음

   • 위 방법들은 모두 코드량이 많아진다는 단점이 있음

2. 스프링 OSIV: 비즈니스 계층 트랜잭션

   • OSIV를 사용하긴 하지만 트랜잭션은 비즈니스 계층에서만 사용

     

     • 클라이언트에서 요청이 들어오면 영속성 컨텍스트를 생성하나 트랜잭션은 시작하지 않는다.
     • 서비스계층에서 트랜잭션을 시작하면 앞에서 생성해둔 영속성 컨텍스트에 트랜잭션을 시작한다.
     • 비즈니스 로직이 끝나면 트랜잭션을 커밋하면서 영속성 컨텍스트를 플러시한다.
     • 이때 트랜잭션만 종료하고 영속성 컨텍스트는 살려두고 클라이언트의 요청이 끝나면 영속성 컨텍스트를 종료한다. 이때 플러시는 발생하지 않음.

   • 트랜잭션 없이 읽기

     • 영속성 컨텍스트를 통한 모든 변경은 트랜잭션 내에서 일어나야한다. 그러나 단순 조회는 트랜잭션이 없어도 가능함.
     • em.flush()를 직접 호출해도 트랜잭션 범위 밖이므로 데이터를 수정할 수 없다는 예외 발생함

   • OSIV 주의 사항

     • 컨트롤러에서 엔티티를 수정하고 바로 서비스계층을 호출할 경우 DB에 수정사항이 반영됨.

       

     • 비즈니스로직을 모두 호출 후에 엔티티를 변경하도록 해야함

     • OSIV를 사용하지 않는다면 트랜잭션의 생명주기와 영속성 컨텍스트의 생명주기가 같으므로 이런 문제가 생기지 않음.

   • OSIV 사용 관련 주의점들

     • 스프링 OSIV 단점
       • 같은 영속성 컨텍스트를 여러 트랜잭션이 공유할 수 있어 롤백시 문제가 될 수 있음
       • 프레젠테이션 계층에서 SQL이 실행되기 때문에 성능 튜닝시 고려범위가 넓음
     • OSIV vs FACADE vs DTO
       • OSIV 승
     • OSIV를 사용하는 것이 무조건 능사는 아님
       • 통계 같은 복잡한 화면을 구성할 때는 JPQL을 직접 작성하여 DTO로 변환하는 것이 더 효과적일 수 있음
     • OSIV는 같은 JVM을 벗어난 원격 상황에서는 사용할 수 없음
       • SPA 등 프론트 백 따로 있으면 별로…

   • OSIV를 사용하면 컨트롤러에서 리포리토리 직접 호출 가능 → 좀 더 유연하고 실용적일 수 있음