study-log

⭐ jpa 1차 캐시

• 1차 캐시란 JPA에서 EntityManager 단위로 관리되는 캐시
• 트랜잭션 범위 내에서 동일한 EntityManager를 통해 조회된 엔티티는 EntityManager 내부 캐시, 메모리에 보관된다.
• 같은 트랜잭션 내에서, 동일한 엔티티를 반복 조회하면 DB에 접근하지 않고 캐시된 객체를 반환한다.

✅ 특징

• 트랜잭션 단위, EntityManager 새명중기와 동일
• flush()전까지 DB에 반영되지 않을 수 있음
• detach(), clear(), close() 하면 1차 캐시 비워짐

✅ JPA EntityManager의 이점

• 1차 캐시 활용으로 동일 트랜잭션 내 불필요한 DB 조회 방지 → 같은 엔티티를 다시 조회해도 DB 하지 않아 성능 이점

• 변경 감지(Dirty Checking) + flush를 통한 자동 update
  EntityManager내 값과 변경사항을 비교, 감지하여 반영 -> setter나 필드 변경만 해도 트랜잭션 커밋 시 자동으로 update

• 트랜잭션 범위 내에서의 일관성 있는 객체 관리 → 하나의 트랜잭션에서 동일 객체 보장, equals/hashCode 비교 유리

• 객체지향 쿼리 지원 → 도메인 중심으로 쿼리 구성 가능

⚠️ 단점 및 주의사항

• DB에 반영되는 시점이 명확하지 않을 수 있음 → flush()가 실행되기 전까지는 실제 DB에 반영되지 않음 → 로그 상에서는 SQL이 보이지 않아서 디버깅 어려움

• 연관관계 위주의 쿼리 작성 유도 → JPA보단 native query가 적합한 경우도 있음
  → n+1 문제

• 예상치 못한 Lazy Loading → 트랜잭션 밖에서 프록시 객체 접근 시 LazyInitializationException

• 성능 튜닝 난이도 존재 → N+1 문제, 복잡한 fetch join 사용 시 성능 예측 어려움

✅ 💤 lazy로딩시 프록시 객체 동작 원리

• 상위 객체는 실제로 DB에서 조회되고, 연관된 객체는 접근 전까지 DB에서 조회되지 않고 해당 클래스 타입의 프록시 객체가 들어가게 된다.
• 프록시 객체(연관 객체)에 접근 시점에 실제 DB에 쿼리를 날리고, 해당 클래스 데이터를 채운후 동작한다.

✅ 프록시 객체

• 실제 객체가 아닌 해당 클래스를 상속해서 만들어진 fake 객체 📌 예) Member$HibernateProxy
• 내부적으로 hibernate가 만든 바이트 코드 기반의 래퍼 클래스
• 실제 필드에는 값이 없음(id만 세팅되어 있을 수 있음)

✍️ 개인 회고

JPA 써봤어요? 어땠어요? 라고 질문을 받아서
EntityManager로 오는 이점도 있지만 단점도 있는 것 같다고 시작해서 답변을 했다.
EntityManager부터 오는 이점이 많지만,
잘 알고 사용하지 않으면 당황할 수 있다. 연관관계 위주로 쿼리를 작성한다거나,
DB에 반영되는 시점이 정확하지 않다거나 하는 점 등을 고려해서 사용해야 할 것 같다.