난 JPA를 제대로 알고 쓰는 것인가 (정리중..)

# 레퍼런스

https://msolo021015.medium.com/jpa-persistence-context-deep-dive-2f36f9bd6214

JPA Persistence Context Deep Dive

#logging.level.org.hibernate.event.internal.AbstractFlushingEventListener=DEBUG

JPA를 쓴다면 OpenEntityManagerInViewFilter를 고려해야한다

 

JPA LazyLoading은 관리하는 세션 사이클에 포함되어 있을 때만가능하다.

트랜잭션 범위를 벗어나면 (View에 전달된 이후에는) 쿼리 호출이 불가능하다. 그래서 트랜잭션이 끝나기전 지연로딩을 강제 호출해야한다

 

그ㅡ래서 Contoller를 벗어난 View까지 LazyLoading 하기위해 OSIV(Open Session In View),

하이버네이트에선 - OpenEntityManagerInViewFilter 이런게 있다.

 

편하긴 하기만, 최적화 관점에서 조심해서 써야한다.

초보 개발자는 쿼리가 실행되는 시점을 예상하지 못한다. ➡ 성능 문제로 발전할 가능성이 높다.

 

요즘에는 SPA가 생겨서 그런고민을 안하긴 한다. 만약 서버에서 처리한다 한들 사용안하는 것도 고려. (SIde-Effect와 이해도를 위해서. @JsoinIgnore, @JsonView 같은 선언이 많아지면..클래스 예측이 어렵다)

 

DTO의 변화는 외부 인터페이스로 의식해서 관리하는 범위가 된다. (Public, Swagger 스펙 활용)

여러 Entity를 조합할 수 있는 여지가 생긴다.

 

---

EntityMangerFactory - 앱 시작시 생성, Was 종료시 함께 종료하며 커넥션 풀을 반환함

 

EntityManger - 내부적으로 DB Connetion pool 가짐, 세션으로 사용되기 때문에 스레드 공유 X

Persistence Context - Entity가 식별자로 관리되는 곳. 여러 EntityManager가 동시에 사용할 수도 있음

 

1차 캐시 (DB 쿼리 안날리기)

- 성능상 큰 이점 없음

 

1차 캐시 동작

➡ 1차 캐시에 조회하고자 하는 Entity가 없다

➡ DB 조회 쿼리를 날린다

➡ Entity를 가져와서 P-Context에 넣는다.

➡ 다음에 같은 식별자를 가진 엔티티를 요청하면, DB쿼리를 날리지 않는다.

즉, 식별자(ID)가 아닌 값으로 쿼리(JPQL)를 날리게되면 새롭게 조회해버린다.

ID로 가져오고 수정했는데, 아직 DB Update를 날리지않았다. 트랜잭션 안닫고 값으로 같은거 조회하면 정합성 깨짐.

아, 물론 JPQL을 사용하면 Flush가 되도록 만들어져있으니 안심하라.

 

➡ 이런 동작은 동일성 보장에도 사용된다. (프록시를 사용해도 동일성을 보장하도록 구현됨)

그러나 OSIV (Open Session In View 세션을 뷰까지 유지해서 Lazy Loading가능하게)

하이버네이트에선 OpenEntityManagerInViewFilter 라고 불리는 걸 사용하면 트랜잭션 범위가 아니라 요청 범위의 캐시로 넓어진다. 이 경우 JPA가 생성하는 쿼리를 알지 못하면 성능 박살날 위험이 있다. 

 

Q. 그럼 2차캐시는 뭔데?

여러명이 사용하는 캐시, Application 전체에 공유하는 캐시

사실 JPA1.0에는 적혀있지 않은 기능으로, 구현체마다 다른 캐시기능을 지원해줬었다.

JPA2.0부터 캐시 표준이 나왔고 세밀한 설정을 하기위해선 구현체에 의존적인 기능을 다뤄야한다.

@Cacheable // 2차캐시 활성화. true는 기본 값이라 생략가능 @Cacheable(value=true)
@Entity
public class Member {
	@Id @GeneratedValue
    private Long id;
    
    ...
}

spring.jpa.properties.hibernate.cache.use_second_level_cache = true
💨 2차 캐시 활성화합니다.
spring.jpa.properties.hibernate.cache.region.factory_class
💨 2차 캐시를 처리할 클래스를 지정합니다.
spring.jpa.properties.hibernate.generate_statistics = true
💨 하이버네이트가 여러 통계정보를 출력하게 해주는데 캐시 적용 여부를 확인할 수 있습니다.

 

참고로 @Cacheable을 안붙이고 사용가능하게 바꿔줄 수 있다.

 spring.jpa.properties.javax.persistence.sharedCache.mode= (기본값) Enable_selective

• ALL : 모든 엔티티를 캐시한다.
• NONE : 캐시를 사용하지 않는다.
• ENABLE_SELECTIVE : Cacheable(true)로 설정된 엔티티만 캐시한다.
• DISABLE_SELECTIVE : 모든 엔티티를 캐시하는데 Cacheable(false)로 명시된 엔티티는 캐시하지 않는다.
• UNSPECIFIED : JPA 구현체가 정의한 설정을 따른다.

 

➡ JPA에서는 공유 캐시(Shared Cache, L2 Cahce)라고 부른다. 분산 or 클러스터링 환경에서는 Application의 생명주기 보다 더 오래 유지되는 경우도 있다.

➡ EntityManager는 1차 캐시에 없으면 2차 캐시에 찾고, 또 없으면 DB에서 찾는다.

잘 활용하면 조회 성능을 획기적으로 줄일 수 있다.

 

하이버네이트 2차 캐시 - 3가지

• 엔티티 캐시(JPA 표준) : 엔티티 단위로 캐시한다. 식별자로 엔티티를 조회하거나 컬렉션이 아닌 연관된 엔티티를 로딩할 때 사용한다.
• 컬렉션 캐시(전용기능) : 엔티티와 연관된 컬렉션을 캐시한다. 컬렉션이 엔티티를 담고 있으면 식별자 값만 캐시한다. 
• 쿼리 캐시(전용기능) : 쿼리와 파라미터 정보를 키로 사용해서 캐시한다. 결과가 엔티티면 식별자 값만 캐시한다. 

@Cacheable
💨 엔티티 캐시 적용시 사용하는 어노테이션

@Cache
💨 하이버네이트 전용입니다.

• usage : CacheConcurrencyStrategy를 사용해서 캐시 동시성 전략을 설정한다.
• region : 캐시 지역 설정
• include : 연관 객체를 캐시에 포함할지 선택한다. all, non-lazy 옵션을 선택할 수 있다. 기본값은 all이다.

 

2차 캐시 동작

➡ 영속성 컨텍스트는 1차 캐시에 없는 엔티티가 필요하면 2차 캐시를 조회한다.

➡ 거기에도 없으면 DB에 조회하고, 결과를 2차 캐시에 보관한다.

➡ 2차 캐시는 자신이 보관하고 있는 엔티티를 복사해서 반환한다.

➡ 원본을 주는게 아니다. 조회시 복사본을 반환한다. (동시성 극대화)

영속성 유닛 범위의 캐시이다. 쉽게 말해 영속성 컨텍스트가 다르다면 객체 동일성을 전혀 보장하지 않는다. 

 

 

엔티티 '등록'시 트랜잭션을 지원하는 쓰기지원

참고로 조회는 지연이 안된다. 뭐가 반환될 줄 어떻게 알고?

조회가 지연되면 조회 시점에 따라 정합성이 깨져버릴 수 있다. 

 

entityManager.persist(memberA)

 

1) memberA가 1차 캐시에 저장한다.
2) 1)과 동시에 JPA가 Entity를 분석하여 insert Query를 만든다.
3) insert Query를 쓰기 지연 SQL 저장소 라는 곳에 쌓는다.
4) DB에 바로 넣지 않고 기다린다.
5) memberB도 동일.

 

transaction.commit()

6) 쓰기 지연 SQL 저장소에 쌓여있는 Query들을 DB로 날린다. flush()

flush() 는 1차캐시를 지우지는 않는다. 쿼리들을 DB에 날려서 DB와 싱크를 맞추는 역할을 한다.
7) flush() 후에 실제 DB에 전달되고 Transaction이 커밋된다. (commit())

 

물론 flush를 직접 호출하는 방법도 있다.

또는 JPQL이 실행되면 flush가 호출된다.

 

JPQL 쓰기 쿼리가 실행되면 플러시가 무조건 호출된다고요?

JPQL 쿼리 실행시 플러시를 자동 호출한다. 설명에 그렇게 적혀있긴하다.

em.persist(memberA);
em.persist(memberB);
em.persist(memberC);

//중간에 JPQL 실행. 위에 있는 A,B,C가 정상적으로 쿼리에 반영이 될까?
query = em.createQuery("select m from Member m", Member.class);
List<Member> members= query.getResultList();

단순한 select 라면 영속성 컨텍스트에서 식별자를 통해 캐싱 하더라도 정합성이 깨지지 않는다.

하지만 JPQL은 쿼리문, 즉 어떤 결과를 가져올지 실행전에는 알 수 없다. 쿼리문의 조건에 따라 결과값이 달라지니까

그래서 JPQL 실행전 flush를 발생시켜 이러한 오류를 방지하는 것이다.

 

😒 : 그럼 식별자ID 를 통한 단순 조회문( em.find() )도 JPQL로 작성하면 무조건 먼저 플러시가 되겠네요?

무조건이 아니다! 상황에 따라 다르다.

➡ em.find()와 똑같은 동작을 하는 JPQL 쿼리문을 작성한 경우 #1 flush가 발생한다.

정합성을 깨뜨리지 않기 위해 앞에 쌓여있던 기존의 작업들이 flush 된다.

➡ em.find()와 똑같은 동작을 하는 JPQL 쿼리문을 작성한 경우 #2 flush가 발생하지 않는다.

놀랍게도 flush가 되지 않은 상태로 JPQL 쿼리가 나갔다. (* flush 설정 바꾼거 없음)

 

Hibernate에서 flush는 아래와 같이 동작한다.

• 트랜잭션을 커밋하기 전
• 영속성 컨텍스트의 쓰기 지연 저장소에 대기 중인 엔터티의 작업과 겹치는 JPQL 쿼리를 실행하기 전
• 네이티브 SQL 쿼리를 실행하기 전

즉, 엔티티 작업이 겹치지 않으면 flush가 발생하지 않는다.

예를 들어 아래와 같은 예제에서,

select a from Article a 는 flush()가 발생하지 않지만

select m from Member a 는 flush()가 발생한다. 영속성 컨텍스트에 대기중인 엔터티 작업이 있기 때문이다.

Member와 상관없는 Article JPQL 쿼리는, flush가 발생하지 않는다.

 

아, 그럼 em.find()는 플러시가 되지 않아서 정합성이 깨질 수도 있겠네요?

이 질문을 이해하려면 SpringDataJPA의 repository.findById() 를 사용하는 아래 예제를 봐야한다.

SpringDataJPA의 findById()는 JPQL을 사용하는게 아니기에, flush가 되지 않는다.

 

그래서 위의 예제처럼 1차 캐시 정합성을 깨뜨려버릴 수 있다.

1. 엔티티를 생성하고, save()를 한다.
   @Id @GeneratedValue(IDENTITY) 라서 키 값을 얻기 위해 DB insert 쿼리가 발생한다 
2. 이후 read()로 같은 객체를 읽어오고, update()로 객체를 수정한다.
   이때는 DB 쿼리가 발생하지 않는다. 식별자(ID)를 통해 Persistence Context 내에서만 변경사항이 저장된다.
3. delete() 로 객체를 삭제한다.
   이 역시 DB 쿼리가 발생하지 않는다. 식별자(ID)를 통해 Persistence Context 내에서만 변경사항이 저장된다.
4. 이후 커밋하기 전에 findById()로 삭제한 객체를 조회한다.
   DB insert 쿼리가 나가고, 아직 delete쿼리가 나가지 않았다.
   즉 DB에는 insert된 값이 남아 있으므로 영속성 컨텍스트에서 삭제한 객체를 DB에서 잘 가져온다.
   이후 가져온 엔티티(=이미 deleted()된 엔티티)를 변경한다면? 정합성이 깨졌다!
5. tx.commit() 이후 DirtyChecking을 통해 DB deleted 쿼리가 발생한다.
    

과연 그럴까?

놀랍게도, 정합성이 깨지지 않았다.

1. DB insert 쿼리가 나갔고 

2. delete() 작업은 쓰기지연이 발동하여 DB 쿼리가 나가지 않았다.

참고로 update는 쿼리가 아예 찍히지 않는다. dirty-checking을 통해 쿼리를 생성하기 때문이다.

JPA 메서드를 호출했다고 해도, 엔티티의 상황에 따라 DB flush가 발생하지 않을 수 있다.

em.flush() 하는 시점에 dirtyChecing이 일어난다.

 3. 그 상태에서 tx.commit() 전에 다시 DB select를 때렸으면...정합성이 깨지면서 가져와져야하는데?

정상 삭제되었다. null이 반환되었다. 정상 삭제되었다. 그 이후 뒤늦게 delete 쿼리가 발생하였다..이게 무슨?

 

정합성이 잘 유지되었다. 어떻게 이게 가능한걸까?

답은 식별자(ID)를 가지고 있었기 때문이다. JPA- hibernate 쿼리를 찍어보자

Entity is null ? : null 로그 바로 이전에 동작을 살펴보면

DefaultLoadEventListener를 통해서 Loading Entity를 확인한 것을 볼 수 있다. 그리고 설명도 친절하게 적혀있는데

CacheEntityLoaderHelper : 
Load request found matching entity in context, but it is scheduled for removal; returning null.

PC에서 엔티티를 찾았지만, 해당 엔티티가 remove 상태로 예약되어있기 때문에 null을 반환한다.

다음 글의 설명 을 빌려오자면 엔티티 상태 전환 작업은 트랜잭션 커밋시에 반영되며, 조기에 flush를 호출하는 것을 방지하기 위해 상태 전환작업은 트랜잭션 마지막에(조회 작업과 안겹치게)사용하라고 권장 한다.

 

하이버네이트 flush 모드를 설정할때, AUTO라고 적은 이유를 이제 조금 알 것같기도 하다.

 

😏 : 그럼 식별자(ID)가 아닌 다른 값으로 조회하면 정합성이 깨지겠네요?

그렇다. 깨진다. 근데 ID가 아닌 다른 값으로 조회 == JPQL의 사용이라서 위에서 적절하게 flush가 동작한다. 

 

당연히 em.setFlushMode(FlushModeType.COMMIT) 으로 JPQL 작업이 flush가 동작하지 않도록 강제로 설정한다면 정합성이 깨진다.

 

또한 예제에서 나온 작업을 JPA를 거치지 않고 똑같이 한다면 당연히 정합성이 깨진다.

예를 들어 아래처럼 jdbcTemplate으로 직접 쿼리를 찍는다거나.

actual = jdbcTemplate.queryForObject("SELECT * FROM member where id = ?", (rs, rowNum) -> {
    Member dbMember = new Member();
    dbMember.setId(rs.getLong("id"));
    dbMember.setUsername(rs.getString("username"));
    return dbMember;
}, member.getId());

 

@Modify 작성예정-