[자바 ORM 표준 JPA 프로그래밍] 15장 고급 주제와 성능 최적화

🎈15.1 예외 처리

15.1.1 JPA 표준 예외 정리

JPA 표준 예외

- 트랜잭션 롤백을 표시하는 예외

- 트랜잭션 롤백을 표시하지 않는 예외

트랜잭션 롤백을 표시하는 예외는 심각한 예외이므로 복구해서는 안 됨. 

 

15.1.2 스프링 프레임워크의 JPA 예외 변환

서비스 계층에서 데이터 접근 계층의 구현 기술에 직접 의존하는 것이 좋은 설계가 아닌 것처럼

서비스 계층에서 JPA의 예외를 직접 사용하면 안됨. 

이런 문제 해결을 위해 스프링 프레임워크는 데이터 접근 계층에 대한 예외를 추상화해서 개발자에게 제공함. 

 

15.1.3 스프링 프레임워크에 JPA 예외 변환기 적용

JPA 예외를 스프링 프레임워크가 제공하는 추상화된 예외로 변경하려면

스프링 빈으로 PersistenceExceptionTranslationPostProcessor를 등록하면 됨. 

 

15.1.4 트랜잭션 롤백 시 주의사항

트랜잭션을 롤백하는 것은 데이터베이스의 반영사항만 롤백하는 것이지

수정한 자바 객체까지 원상태로 복구해주지는 않음. 

 

기본 전략인 트랜잭션당 영속성 컨텍스트 전략은 문제가 발생하면 트랜잭션 AOP 종료 시점에 트랜잭션을 롤백하면서 영속성 컨텍스트도 함께 종료하므로 문제가 발생하지 않는다. 

 

OSIV처럼 영속성 컨텍스트 범위를 트랜잭션 범위보다 넓게 사용할 때.

스프링 프레임워크는 영속성 컨텍스트의 범위를 트랜잭션의 범위보다 넓게 설정하면 트랜잭션 롤백시 영속성 컨텍스트를 초기화해서 잘못된 영속성 컨텍스트를 사용하는 문제를 예방함. 

 

 

 

 

🎈15.2 엔티티 비교

15.2.1 영속성 컨텍스트가 같을 때 엔티티 비교

member와 findMember가 완전히 같은 인스턴스. 같은 트랜잭션 범위에 있으므로 같은 영속성 컨텍스트를 사용하기 때문.

동일성: == 비교가 같음. 

동등성: equals() 비교가 같음.

데이터베이스 동등성: @Id 인 데이터베이스 식별자가 같음. 

 

 

 

15.2.2 영속성 컨텍스트가 다를 때 엔티티 비교

 

member와 findMember는 각각 다른 영속성 컨텍스트에서 관리되었기 때문에 둘은 다른 인스턴스임. 

동일성(identical): == 비교가 실패함.

동등성(equivalent): equals() 비교가 만족함. 

데이터베이스 동등성: @Id인 데이터베이스 식별자가 같음. 

 

 

동일성 비교는 같은 영속성 컨텍스트의 관리를 받는 영속 상태의 엔티티에만 적용할 수 있다. 

그렇지 않을 때는 비즈니스 키를 사용한 동등성 비교를 해야 한다. 

 

 

 

🎈15.3 프록시 심화 주제

15.3.1 영속성 컨텍스트와 프록시

영속성 컨텍스트는 프록시로 조회된 엔티티에 대해서 같은 엔티티를 찾는 요청이 들어오면 원본 엔티티가 아닌 처음 조회된 프록시를 반환함. 

따라서 프록시로 조회해도 영속성 컨텍스트는 영속 엔티티의 동일성을 보장함. 

 

원본 엔티티를 먼저 조회하는 경우, 영속성 컨텍스트는 원본 엔티티를 이미 데베에서 조회했으므로 프록시를 반환할 이유가 없음. 따라서 em.getReference()를 호출해도 프록시가 아닌 원본을 반환하고, 영속 엔티티의 동일성을 보장함. 

 

 

15.3.2 프록시 타입 비교

프록시는 원본 엔티티를 상속 받아서 만들어지므로 프록시로 조회한 엔티티의 타입을 비교할 때는 == 비교를 하면 안 되고 instanceof를 사용해야 함. 

@Test
public void 프록시_타입비교() {
	Member newMember = new Member("member1", "회원1");
    em.persist(newMember);
    em.flush();
    em.clear();
    
    Member refMember = em.getReference(Member.class, "member1");
    
    System.out.println("refMember Type = " + refMember.getClass());
    
    Assert.assertFalse(Member.class == refMember.getClass()); //false
    Assert.assertTrue(refMember instanceof Member); //true
}

 

 

15.3.3 프록시 동등성 비교

프록시와 equals() 비교를 할 때의 주의점

 

- 프록시는 원본을 상속받은 자식 타입이므로 프록시의 타입 비교는 == 비교 대신에 instanceof를 사용해야 한다. 

- 프록시는 실제 데이터를 가지고 있지 않으므로 프록시의 멤버변수에 직접 접근하면 안 되고 대신에 접근자 메소드를 사용해야 한다. 

 

@Override
public boolean equals(Object obj) {
    if (this == obj) return true;
    if (!(obj instanceof Member)) return false;
    
    Member member = (Member) obj;
    
    if (name != null ? !name.equals(member.getName()) :
    	member.getName() != null)
        return false;
        
    return true;
}

 

 

15.3.4 상속관계와 프록시

프록시를 부모 타입으로 조회하면 부모의 타입을 기반으로 프록시가 생성되는 문제가 있음. 

- instanceof 연산을 사용할 수 없음. 

- 하위 타입으로 다운캐스팅을 할 수 없음. 

@Test
public void 상속관계와_프록시_도메인모델() {
	//테스트 데이터 준비
    Book book = new Book();
    book.setName("jpabook");
    book.setAuthor("kim");
    em.persist(book);
    
    OrderItem saveOrderItem = new OrderItem();
    saveOrderItem.setItem(book);
    em.persist(saveOrderItem);
    
    em.flush();
    em.clear();
    
    //테스트 시작
    OrderItem orderItem = em.find(OrderItem.class, saveOrderItem.getId());
    Item item = orderItem.getItem();
    
    System.out.println("item = " + item.getClass());
    
    //결과 검증
    Assert.assertFalse(item.getClass() == Book.class);
    Assert.assertFalse(item instanceof Book);
    Assert.assertTrue(item instanceof Item);

 

 

문제 해결 방법

JPQL로 대상 직접 조회

처음부터 자식 타입을 직접 조회해서 필요한 연산을 하면 됨. 하지만 다형성을 활용할 수 없음. 

Book jpqlBook = em.createQuery
    ("select b from Book b where b.id=:bookId", Book.class)
    	.setParameter("bookId", item.getId())
    	.getSingleResult();

 

프록시 벗기기

//하이버네이트가 제공하는 프록시에서 원본 엔티티를 찾는 기능을 사용하는 메소드
public static <T> T unProxy(Object entity) {
    if(entity instanceof HibernateProxy) {
    	entity = ((HibernateProxy) entity)
        			.getHibernateLazyInitializer()
                    .getImplementation();
    }
    return (T) entity;
}

한 번 프록시로 노출한 엔티티는 계속 프록시로 노출해서 영속성 컨텍스트가 영속 엔티티의 동일성을 보장한다고 했는데 

이 방법은 프록시에서 원본 데이터를 직접 꺼내기 때문에 프록시와 원본 엔티티의 동일성 비교가 실패한다는 문제점이 있음. (item == unProxyItem의 결과는 false라는 문제.)

 

 

기능을 위한 별도의 인터페이스 제공

인터페이스를 제공하고 각각의 클래스가 자신에 맞는 기능을 구현하하는 것은 다형성을 활용하는 좋은 방법.

클라이언트 입장에서 대상 객체가 프록시인지 아닌지를 고민하지 않아도 되는 장점이 있음. 

 

비지터 패턴 사용

Visitor와 Visitor를 받아들이는 대상 클래스로 구성됨. Item이 accept 메소드로 Visitor를 받아들이기만 하고 실제 로직은 Visitor가 처리함. 

//Visitor 인터페이스
public interface Visitor {
    void visit(Book book);
    void visit(Album album);
    void visit(Movie movie);
}

//비지터 구현

public class PrintVisitor implements Visitor {
    @Override
    public void visit(Book book) {
    	//넘어오는 book은 Proxy가 아닌 원본 엔티티다.
        System.out.println("book.class = " + book.getClass());
        System.out.println("[PrintVisitor]
        	[제목:" + book.getName() + "저자:" + book.getAuthor() + "]");
	}
    
    @Override
    public void visit(Album album) {...}
    @Override
    public void visit(Movie movie) {...}
}

public class TitleVisitor implements Visitor {
    private String title;
    
    public String getTitle() {
    	return title;
    }
    
    @Override
    public void visit(Book book) {
    	title = "[제목:" + book.getName() + "저자:" +
        	book.getAuthor() + "]";
    }
    
    @Override
    public void visit(Album album) {...}
    @Override
    public void visit(Movie movie) {...}
}

 

//비지터 대상 클래스
@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "DTYPE")
public abstract class Item {
	
    @Id@GeneratedValue
    @Column(name = "ITEM_ID")
    private Long id;
    
    private String name;
    
    ...
    
    public abstract void accept(Visitor visitor);
}

@Entity
@DiscriminatorValue("B")
public class Book extends Item {
	
    private String author;
    private String isbn;
    //Getter, Setter
    public String getAuthor() {
    	return author;
    }
}

@Entity
@DiscriminatorValue("M")
public class Movie extends Item {
	...
    @Override
    public void accept(Visitor visitor) {
    	visitor.visit(this);
    }
}

@Entity
@DiscriminatorValue("A")
public class Album extends Item {
	...
    @Override
    public void accept(Visitor visitor) {
    	visitor.visit(this);
    }
}

비지터 패턴을 사용하면 프록시에 대한 걱정 없이 안전하게 원본 엔티티에 접근할 수 있고 instanceof나 타입캐스팅 없이 코드를 구현할 수 있는 장점이 있다. 

 

비지터 패턴의 장점

- 프록시에 대한 걱정 없이 안전하게 원본 엔티티에 접근할 수 있다. 

- instnaceof와 타입캐스팅 없이 코드를 구현할 수 있다. 

- 알고리즘과 객체 구조를 분리해서 구조를 수정하지 않고 새로운 동작을 추가할 수 있다. 

 

비지터 패턴의 단점

- 너무 복잡하고 더블 디스패치를 사용하기 때문에 이해하기 어렵다.

- 객체 구조가 변경되면 모든 Visitor를 수정해야 한다. 

 

 

 

🎈15.4 성능 최적화

15.4.1 N+1 문제

즉시 로딩과 N+1

특정 회원을 em.find() 메소드로 조회하면 즉시 로딩으로 설정한 주문정보도 함께 조회한다. 

em.find(Member.class, id);

-> 실행되는 SQL:

SELECT M.*, O.*

FROM

MEMBER M

OUTER JOIN ORDERS O ON M.ID=O.MEMBER_ID

SQL을 두 번 실행하는 것이 아니라 조인을 사용해서 한 번의 SQL로 회원과 주문정보를 함께 조회함. 

 

문제는 JPQL을 사용할 때 발생함. 

List<Member> members = 
    em.createQuery("select m from Member m", Member.class)
    .getResultList();

JPQL을 실행하면 JPA는 이것을 분석해서 SQL을 생성함. 이때는 즉시 로딩 지연 로딩에 대해 전혀 신경 쓰지 않고 JPQL만 사용해서 SQL을 생성해서 다음과 같은 SQL이 실행됨. 

SELECT * FROM MEMBER
SELECT * FROM ORDERS WHERE MEMBER_ID=1
SELECT * FROM ORDERS WHERE MEMBER_ID=2
...
SELECT * FROM ORDERS WHERE MEMBER_ID=N

이처럼 처음 실행한 SQL의 결과 수만큼 추가로 SQL을 실행하는 것을 N+1 문제라 한다. 

 

 

지연 로딩과 N+1

다음처럼 모든 회원에 대해 연관된 주문 컬렉션을 사용할 때 N+1 문제가 발생함. 

for (Member member : members) {
    //지연 로딩 초기화
    System.out.println("member = " + member.getOrders().size());
}

주문 컬렉션을 초기화하는 수만큼 SQL이 실행됨. 회원이 5명이면 회원에 따른 주문도 5번 조회됨. 

 

 

페치 조인 사용

페치 조인은 SQL 조인을 사용해서 연관된 엔티티를 함께 조회하므로 N+1 문제가 발생하지 않음. 

페치 조인을 사용하는 JPQL select m from Member m join fetch m.orders 를 사용하면

SELECT M.*, O.* FROM MEMBERS M

INNER JOIN ORDERS O ON M.ID=O.MEMBER_ID 가 실행됨.

 

 

하이버네이트 @BatchSize

하이버네이트가 제공하는 BatchSize 어노테이션을 사용하면 연관된 엔티티를 조회할 때 지정한 size만큼 SQL의 IN절을 사용해서 조회함. 조회한 회원이 10명인데 size=5로 지정하면 2번의 SQL만 추가로 실행함. 

 

 

하이버네이트 @Fetch(FetchMode.SUBSELECT)

연관된 데이터를 조회할 때 서브 쿼리를 사용해서 N+1문제를 해결함. 

select m from Member m where m.id > 10

SELECT O FROM ORDERS O
  WHERE O.MEMBER_ID IN (
  	SELECT
    	M.ID
    FROM
    	MEMBER M
    WHERE M.ID > 10
  )

 

 

15.4.2 읽기 전용 쿼리의 성능 최적화

영속성 컨텍스트는 변경 감지를 위해 스냅샷 인스턴스를 보관하므로 더 많은 메모리를 사용한다는 단점이 있음. 

엔티티를 딱 한 번만 읽어서 화면에 출력하고 다시 조회하거나 수정할 일이 없다면 읽기 전용으로 엔티티를 조회하면 메모리 사용량을 최적화할 수 있다. 

스칼라 타입으로 조회

select o.id, o.name, o.price from Order p

스칼라 타입은 영속성 컨텍스트가 결과를 관리하지 않으므로 가장 확실한 방법은 엔티티가 아닌 스칼라 타입으로 모든 필드를 조회하는 것. 

 

읽기 전용 쿼리 힌트 사용

하이버네이트 전용 힌트인 org.hibernate.readOnly를 사용하면 엔티티를 읽기 전용으로 조회할 수 있음. 

 

읽기 전용 트랜잭션 사용

스프링 프레임워크를 사용하면 트랜잭션을 읽기 전용 모드로 설정할 수 있음. 

@Transactional(readOnly = true)

트랜잭션을 커밋해도 영속성 컨텍스트를 플러시하지 않으므로 엔티티의 등록, 수정, 삭제는 당연히 동작하지 않고, 스냅샷 비교와 같은 무거운 로직들을 수행하지 않아 성능이 향상됨. 

 

트랜잭션 밖에서 읽기

트랜잭션 없이 엔티티를 조회하는 방법. 

스프링 프레임워크에서는

@Transactional(propagation = Propagation.NOT_SUPPORTED)

로 설정함. 

 

 

15.4.3 배치 처리

수백만 건의 데이터를 배치 처리해야 한다고 가정하면

일반적인 방식으로 조회하면 영속성 컨텍스트에 많은 엔티티가 쌓여 메모리 부족 오류가 발생함. 

 

JPA 등록 배치

많은 엔티티를 한 번에 등록할 때는

영속성 컨텍스트에 엔티티가 계속 쌓이지 않도록 일정 단위마다 영속성 컨텍스트의 엔티티를 데이터베이스에 플러시하고 영속성 컨텍스트를 초기화해야 함. 

EntityManager em = entityManagerFactory.createEntityManager();
EntityTranssaction tx = em.getTransaction();
tx.begin();

for (int i = 0; i < 10000; i++) {
	Product product = new Product("item" + i, 10000);
    em.persist(product);
    
    //100건마다 플러시와 영속성 컨텍스트 초기화
    if(i % 100 == 0) {
    	em.flush();
        em.clear();
    }
}

tx.commit();
em.close();

 

 

다음으로 수정 배치 처리를 할 때는 페이징 처리 또는 커서 방법을 사용함. 

JPA 페이징 처리

100건씩 페이징 쿼리로 조회하면서 상품의 가격을 100원씩 증가하고, 페이지 단위마다 영속성 컨텍스트를 플러시하고 조기화함. 

 

하이버네이트 scroll 사용

JPA는 JDBC 커서를 지원하지 않아 커서를 사용하려면 하이버네이트 세션을 사용해야 함. 

em.unwrap() 메소드를 사용해서 하이버네이트 세션을 구함. 다음으로 쿼리를 조회하면서 scroll() 메소드로 ScrollableResults 객체를 반환받음. 이 객체의 next()  메소드를 호출하면 엔티티를 하나씩 조회할 수 있음. 

 

하이버네이트 무상태 세션 사용

무상태 세션은 영속성 컨텍스트를 만들지 않고 2차 캐시도 사용하지 않음. 따라서 영속성 컨텍스트를 플러시하거나 초기화하지 않아도 됨. 

엔티티를 수정하려면 무상태 세션이 제공하는 update() 메소드를 직접 호출해야 함. 

 

 

15.4.4 SQL 쿼리 힌트 사용

JPQ는 데이터베이스 SQL 힌트 기능을 제공하지 않아 SQL 힌트를 사용하려면 하이버네이트를 직접 사용해야 함. 

Session session = em.unwrap(Session.class); //하이버네이트 직접 사용

List<Member> list = session.createQuery("select m from Member m")
	.addQueryHint("FULL (MEMBER)") //SQL HINT 추가
    .list();
    
    

select
	/* + FULL (MEMBER) */ m.id, m.name
from
	Member m

 

 

15.4.5 트랜잭션을 지원하는 쓰기 지연과 성능 최적화

트랜잭션을 지원하는 쓰기 지연과 JDBC 배치

JDBC가 제공하는 SQL 배치 기능을 사용하면 SQL을 모아서 데이터베이스에 한번에 보낼 수 있음. 

SQL 배치는 같은 SQL일 때만 유효해서 중간에 다른 처리가 들어가면 SQL 배치를 다시 시작함. 

 

트랜잭션을 지원하는 쓰기 지연과 애플리케이션 확장성

트랜잭션을 지원하는 쓰기 지연과 변경 감지 기능의 장점은 데이터베이스 테이블 로우에 락이 걸리는 시간을 최소화한다는 점이다. 

update(memberA); //UPDATE SQL A
비즈니스로직A(); //UPDATE SQL ...
비즈니스로직B(); //UPDATE SQL ...
commit();

JPQ는 커밋을 해야 플러시를 호출하고 데이터베이스에 수정 쿼리를 보냄. 쿼리를 보내고 바로 트랜잭션을 커밋하므로 결과적으로 데이터베이스에 락이 걸리는 시간을 최소화한다.