JPA (28) 썸네일형 리스트형 13.3.3 OSIV 정리 - 스프링 OSIV의 특징 - OSIV는 클라이언트의 요청이 들어올 때 영속성 컨텍스트를 생성해서 요청이 끝날때 까지 같은 영속성 컨텍스트를 유지한다. 따라서 한 번 조회한 엔티티는 요청이 끝날 때까지 영속상태를 유지한다. - 엔티티 수정은 트랜젝션이 있는 계층에서만 동작한다. 트랜젝션이 없는 프리젠테이션 계층은 지연 로딩을 포함해서 조회만 할 수 있다. - 스프링 OSIV의 단점 - OSIV를 적용하면 같은 영속성 컨텍스트를 여러 트랜젝션이 공유할 수 있다는 점을 주의해야 한다. 특히 트랜젝션 롤백 시 주의해야 한다. - 프리젠테이션 계층에서 엔티티를 수정하고 나서 비즈니스 로직을 수행하면 엔티티가 수정될 수 있다. - 프리젠테이션 계층에서 지연로딩에 의한 SQL이 실행된다. 따라서 성능 튜닝시에 확인.. 13.3.2 스프링 OSIV : 비즈니스 계층 트랜잭션 스프링 프레임 워크가 제공하는 OSIV는 비즈니스 계층에서 트랜잭션을 사용하는 OSIV다. 이름 그대로 OSIV를 사용하지만 트랜잭션은 비즈니스 계층에서만 사용한다는 뜻이다. - 동작원리 - 클라이언트의 요청이 들어오면 영속성 컨텍스트를 생성한다. 이때 트랜젝션을 생성하지 않는다. - 서비스 계층에서 트랜젝션을 시작하면 앞에서 생성해둔 영속성 컨텍스트에 트랜젝션을 시작한다. - 비즈니스 로직을 실행하고 서비스 계층이 끝나면 트랜젝션을 커밋하면서 영속성 컨텍스트를 플러시한다. - 이후 클라이언트의 요청이 끝날 때 영속성 컨텍스트를 종료한다. 1. 클라이언트의 요청이 들어오면 서블릿 필터나, 스프링 인터셉터에서 영속성 컨텍스트를 생성한다. 단 이때 트랜잭션을 시작하지는 않는다. 2. 서비스 계층에서 @Tra.. 13.3 OSIV OSIV(Open Session In View)는 영속성 컨텍스트를 뷰까지 열어둔다는 뜻이다. 영속성 컨텍스트가 살아있으면 엔티티는 영속상태로 유지된다. 따라서 뷰에서도 지연로딩을 사용할 수 있다. 13.3.1 과거 OSIV: 요청당 트랜잭션 OSIV의 핵심은 뷰에서도 지연로딩이 가능하도록 하는 것이다. 가장 단순한 구현방법은 클라이언트의 요청이 들어오자마자 서블릿 필터나 스프링 인터셉터에서 트랜잭션을 시작하고 요청이 끝날 때 트랜잭션도 끝나는 것이다. 이것을 요청당 트랜잭션 방식의 OSIV라 한다. - 요청당 트랜잭션 방식의 문제점 - 컨트롤러나 뷰 같은 프리젠테이션 계층이 엔티티를 변경할 수 있다는 점이다. - 엔티티를 읽기 전용 인터페이스로 제공 - 엔티티 수정 불가능 interface Member.. 13.2.4 FACADE 계층 추가 class OrderFacade { @Autowired OrderService orderService; public Order findOrder(id) { Order order = orderService.findOrder(id); order.getMember().getName(); return order; } } class OrderService { public Order findOrder(id) { return orderRepository. findOrder(id); } } FACADE 계층의 역할과 특징 - 프리젠테이션 계층과 도메인 모델 계층 간의 논리적 의존성을 분리해준다. - 프리젠테이션 계층에서 필요한 프록시 객체를 초기화한다. - 서비스 계층을 호출해서 비즈니스 로직을 실행한다. - 리포지토.. 13.2.2 JPQL 페치조인 페치조인을 사용하게 되면 SQL JOIN을 사용해서 페치조인 대상까지 함께 조회한다. 따라서 N+1문제가 발생하지 않는다. -> 페치조인은 N+1문제를 해결하면서 화면에 필요한 엔티티를 미리 로딩하는 현실적인 방법이다. JPQL 페치조인의 단점 페치조인이 현실적인 대안이긴 하지만, 무분별하게 사용하면 화면에 맞춘 리포지토리 메소드가 증가할 수 있다. 결국 프리젠테이션 계층이 알게 모르게 데이터 접근 계층을 침범하는 것이다. - 화면 A를 위해 order만 조회하는 repository.findOrder() 메소드 - 화면 B를 위해 order와 연관된 member를 페치조인으로 조회하는 repository.findOrderWithMember 메소드 13.2.3 강제로 초기화 강제로 초기화하기는 영속성 컨텍.. 13.2.1 글로벌 페치 전략 수정 @Entity public class Order { @Id @GeneratedValue private Long id; @ManyToOne(fetch = FetchType.EAGER) //즉시 로딩 전략 private Member member; //주문회원 } Order order = orderService.findOne(orderId); Member member = order.getMember(); member.getName(); //이미 로딩된 엔티티 엔티티에 있는 fetch 타입을 변경하면 애플리케이션 전체에서 이 엔티티를 로딩할 때마다 해당전략을 사용하므오 글로벌 페치 전략이라 한다. FetchType.EAGER로 설정하고 엔티티 매니저로 주문 엔티티를 조회하면 연관된 member 엔티티도 항상 함.. 13.1 트랜잭션 범위의 영속성 컨텍스트 13.1.1 스프링 컨테이너의 기본 전략 스프링 컨테이너는 트랜잭션 범위의 영속성 컨텍스트 전략을 기본으로 사용한다. 이 전략은 이름 그대로 트랜잭션의 범위와 영속성 컨택스트의 생존범위가 같다는 뜻이다. 좀 더 풀어서 이야기하자면 이 전략은 트랜잭션을 시작할 때 영속성 컨텍스트를 생성하고 트랜잭션이 끝날 때 영속성 컨텍스트를 종료한다. 그리고 같은 트랜잭션 안에서는 항상 같은 영속성 컨텐스트에 접근한다. 스프링 프레임워크를 사용하면 보통 비즈니스 로직을 시작하는 서비스 계층에 @Transactional 어노테이션을 선언해서 트랜젝션을 시작한다. 외부에서는 단순히 서비스 계층의 메소드를 호출하는 것처럼 보이지만 이 어노테이션이 있으면 호출한 메소드를 실행하기 직전에 스프링의 트랜젝션 AOP가 먼저 동작한다.. 7.3.3 복합키 : 식별관계 매핑 부모, 자식, 손자까지 계속 기본 키를 전달하는 식별 관계다. @IdClass와 식별 관계 //부모 @Entity public class Parent { @Id @Column(name = "PARENT_ID") private String id; private String name; } @Entity @IdClass(ChildId.class) public class Child { @Id @ManyToOne @JoinColumn(name = "PARENT_ID") public Parent parent; @Id @Column(name = "CHILD_ID") private String childId; private String name; } //자식 Id public class ChildId implement.. 7.2 @MappedSuperClass 부모 클래스는 테이블과 매핑하지 않고 부모 클래스를 상속받는 자식 클래스에게 매핑 정보만 제공하고 싶으면 @MappedSuperClass를 사용하면 된다. @MappedSuperClass는 비유를 하자면 추상 클래스와 비슷한데 @Entity는 실제 테이블과 매핑되지만 @MappedSuperClasssms 실제 테이블과 매핑되지 않는다. 단순히 매핑정보를 상속할 목적으로만 사용된다. @MappedSuperClass public abstract class BaseEntity { @Id @GeneratedValue private Long id; private String name; } @Entity public class Member extends BaseEntity { //ID 상속 //NAME 상속 pri.. 7.1 상속관계 매핑 객체의 상속구조와 데이터베이스의 슈퍼타입 서브타입 관계를 매핑 시키는 것. 슈퍼타입 서브타입 논리 모델을 실제 물리 모델인 테이블로 구현할 때는 3가지 방법을 선택할 수 있다. - 각각의 테이블로 변환 : 각각을 모두 테이블로 만들고 조회할 때 조인을 사용한다. JPA에서는 조인 전략이라고 한다. - 통합 테이블로 변환 : 테이블을 하나만 사용해서 통합한다. JPA에서는 단일 테이블 전략이라 한다. - 서브타입 테이블로 변환 : 서브 타입마다 하나의 테이블을 만든다. JPA에서는 구현 클래스마다 테이블 전략이라 한다. 7.1.1 조인전략 조인 전략은 엔티티 각각을 모두 테이블로 만들고 자식 테이블이 부모테이블의 기본 키를 받아서 기본키 + 외래키로 사용하는 전략이다. 따라서 조회할 때 조인을 자주 사용한.. 이전 1 2 3 다음