조용한 개발 노트

18편에서는 Batch Insert / Update가“왜 JPA의 기본 전략이 될 수 없는지”를 엔티티 상태 기반 쓰기 모델 관점에서 정리했습니다.이번 글에서는 JPA 위에 한 겹 더 얹힌 추상화,Spring Data JPA Repository가우리에게 무엇을 주었고, 대신 무엇을 가려버렸는지를 공식 문서 관점에서 정리해보겠습니다.1. Repository 추상화는 왜 등장했을까Spring Data JPA의 목표는 아주 명확했습니다.“데이터 접근 코드를 최대한 단순하게 만들자”그래서 Repository는EntityManager 직접 사용 ❌반복적인 CRUD 코드 ❌를 숨기고,인터페이스 선언만으로기본 구현을 자동 제공하는 방향을 선택했습니다.이 선택은 생산성 측면에서압도적인 성공이었습니다.2. Reposit..

8편에서는 EntityManager가 왜 Thread-safe 하지 않은지, 그리고 그 이유가“EntityManager는 트랜잭션에 바인딩된 상태 관리자”라는 점에 있음을 정리했습니다.이번 글에서는 이 논의를 한 단계 더 밀어보겠습니다.트랜잭션이 없으면 JPA는 실제로 어떻게 동작할까?결론부터 말하면,트랜잭션이 없는 JPA는 핵심 기능의 절반이 동작하지 않습니다.그래서 우리는“JPA는 트랜잭션 기반 기술”이라고 말합니다.1. 가장 흔한 착각부터 짚자다음과 같은 코드를 보면 많은 개발자가 이렇게 기대합니다.public void updateMember() { Member m = em.find(Member.class, 1L); m.setName("newName");}겉보기에는:엔티티를 조회했고상태를..

7편에서는 영속성 컨텍스트와의 연결을 끊는 행위,detach / clear / merge가 왜 위험하고, 언제 필요한지를 살펴봤습니다.이번 글에서는 그 모든 동작의 중심에 있는 객체,EntityManager가왜 Thread-safe 하지 않은지를 Spring JPA 공식 문서 기준으로 트랜잭션 · 스레드 · 영속성 컨텍스트 관점에서 정리해보겠습니다.1. 많은 개발자가 처음 던지는 질문Spring 환경에서 우리는 보통 다음과 같은 코드를 작성합니다.@Repositorypublic class MemberRepository { @PersistenceContext private EntityManager em;}이 코드를 보면 자연스럽게 이런 의문이 듭니다.EntityManager는 싱글톤 Bean인데..

6편에서는 Flush가“쓰기 SQL을 DB로 전송해 일관성을 맞추는 단계”라는 점을 정리했습니다.이번 글에서는 그 Flush 이후에 등장하는,영속성 컨텍스트와의 연결을 끊는 행위즉, detach, clear, merge가 왜 위험하고, 언제 필요한지를 공식 문서 관점에서 풀어보겠습니다.이 세 가지를 이해하지 못하면,왜 데이터가 사라진 것처럼 보이는지왜 UPDATE가 두 번 나가는지왜 운영에서 재현이 어려운 버그가 생기는지를 설명할 수 없습니다.1. 영속성 컨텍스트와 “연결”의 의미먼저 전제를 다시 짚어야 합니다.엔티티가 영속 상태라는 것은,Persistence Context가 해당 객체의 상태 변화를 추적하고 있다는 의미입니다.이 연결이 유지되는 한,Dirty CheckingFlush가 자동으로 작동합니..

4편에서는 Persistence Context가 단순한 캐시가 아니라,엔티티의 상태와 동일성을 지키기 위한 규칙 집합이라는 점을 살펴봤습니다.이번 글에서는 그 Persistence Context가 가장 강하게 모습을 드러내는 지점,변경 감지(Dirty Checking)를 공식 문서 관점에서 구조적으로 풀어보겠습니다.1. JPA에서 UPDATE는 왜 직접 호출하지 않을까JPA를 처음 접하면 이 점이 가장 낯설게 느껴집니다.member.setName("newName");// update 쿼리는 어디 있지?SQL을 직접 쓰던 시절이라면, 이 코드는아무 일도 하지 않은 코드처럼 보입니다.하지만 JPA에서는 이 한 줄이UPDATE SQL의 의도를 표현합니다.이게 가능한 이유가 바로 변경 감지입니다.2. 변경 감지..