영속성 관련 이슈

응답 값으로 엔티티를 직접 노출 한 경우

문제점

• 엔티티의 모든 값 추가
• 응답 스팩을 맞추기 위한 로직 추가
• api스팩에 대한 변경에 대응하기 어려움

Fetch Join

장점

• SQL 한번으로 연관된 엔티티를 함께 조회할 수 있어 SQL 호출 횟수를 줄여 성능 최적화 가능

단점

• 1대 다 fetch join 페이징 불가능
• 컬렉션 둘 이상의 패치조인 사용하면 안됨 ⇒ 데이터가 부정합하게 조회 될수 있음

ex)

em.createQuery(
    "select o from Order o join fetch o.member m join fetch o.deleveryd",Order.class
).getResultList();

distinct

• jpa 의 distinct는 디비의 distinct 엔티티의 중복인 경우 중복을 걸러서 보내줌

페이징 처리를 하며 Collection 한계 돌파

• ToOne(OneToOne, ManyToOne)모두 패치 조인

• 컬렉션은 지연 로딩으로 조회

• 지연 로딩을 최적화 하기위해 hibernate.default_batch_fetch_size (inquery 갯수)/ @BatchSize 둘중 하나 사용

• @BatchSize : 개별 최적화

• hibernate.default_batch_fetch_size : 글로벌 설정

• 이 옵션을 사용하면 컬렉션이나, 프록시 객체를 한꺼번에 설정한 size만큼 IN쿼리로 조회

• 한계 )

em.createQuery(
    "select distinct o from Order o" + 
    "join fetch o.member m "+ //order 입장 패치 가능
    "join fetch o.delivery d "+  // order 입장 패치 가능
    "join fetch o.orderItems oi " //order 입장 패치 불가능  ToOne관계 아님
    "join fetch oi.item i", Order.class)  // 1대n 관계 관련으로 패치조인 불가능

• 해결책)

public List<orderDto> order(@RequestParam(value="offset", default
em.createQuery(
    "select o from Order o"+
    "join fetch o.member m" +
    "join fetch o.delivery d", Order.class)
    .setFirstResult(offset)
    .setMaxResults(limit)
    .getResultList();
)

결론

• ToOne관계는 패치조인 사용
• 나머지는 hibernate.default_batch_fetch_size 로 최적화 (max : 1000 min:100)

트랜잭션

트랜잭션의 성질

원자성

• 한 트랜잭션 내에서 실행한 작업들은 하나로 간주한다. 즉, 모두 성공 또는 모두 실패

일관성

• 트랜잭션은 일관성 있는 디비 상태를 유지

격리성

• 동시에 실행되는 트랜잭션들이 서로 영향을 미치지 않도록 격리

지속성

• 트랜잭션을 성공적으로 마치면 결과가 항상 저장되야함