🌱 TIL - JPA와 영속성 컨텍스트

JPA와 영속성 컨텍스트에 대해 알아보자

Spring Boot에서 JPA를 배우기 시작하면 가장 자주 듣는 개념 중 하나가 바로 영속성 컨텍스트다.
처음에는 그냥 Entity를 저장해두는 공간 정도로만 생각했는데, 정리해보니 JPA의 핵심 동작 대부분이 이 영속성 컨텍스트를 기준으로 이루어지고 있었다.

이번 글에서는 JPA가 무엇인지, 그리고 영속성 컨텍스트가 왜 중요한지를 중심으로 정리해보려고 한다.

🍓 JPA란?

JPA는 Java Persistence API의 약자다.
자바에서 ORM 기술을 사용하기 위한 표준 명세라고 보면 된다.
여기서 ORM은 객체와 관계형 데이터베이스를 매핑하는 기술이다.

즉, 자바 객체를 테이블과 연결해서 객체 중심으로 개발할 수 있도록 도와주는 방식이다.

예전처럼 JDBC를 사용할 때는 다음 과정을 반복해야 했다.

• SQL 직접 작성
• 파라미터 바인딩
• 조회 결과를 다시 객체로 변환

반면 JPA를 사용하면 Entity와 테이블을 매핑해두고, 객체를 중심으로 코드를 작성할 수 있다.

참고로 JPA는 구현체가 아니라 명세이기 때문에, 실제로는 Hibernate 같은 구현체가 JPA를 동작하게 해준다.
hibernate가 사실상 표준이다.

🍊 영속성 컨텍스트란?

영속성 컨텍스트는 Entity 객체를 관리하는 공간이다.

JPA는 DB에 바로 SQL을 날리는 방식이 아니라, 중간에 영속성 컨텍스트를 두고 Entity를 관리한다. 그리고 이 영속성 컨텍스트를 다루는 객체가 바로 EntityManager다.

• EntityManager : Entity를 저장, 조회, 수정, 삭제하는 역할 수행
• EntityManagerFactory : EntityManager를 생성하는 공장 역할 수행

처음엔 그냥 DB에 바로 저장하면 되는 거 아닌가? 싶었는데, 영속성 컨텍스트가 있기 때문에 JPA는 단순 CRUD를 넘어서 여러 편리한 기능을 제공할 수 있다.

• 1차 캐시
• 쓰기 지연
• 변경 감지

🍋 영속성 컨텍스트가 중요한 이유

1. 1차 캐시

영속성 컨텍스트 내부에는 1차 캐시가 있다.

Entity를 조회하면 이 캐시에 저장되고, 같은 트랜잭션 안에서 같은 Entity를 다시 조회할 때는 DB를 다시 조회하지 않고 캐시에서 가져온다.

처음 조회할 때는 DB 접근, 같은 트랜잭션 안에서 다시 조회할 때는 캐시에서 반환

이 기능의 장점은 단순히 조회 성능만이 아니다.
같은 트랜잭션 안에서는 같은 Entity를 다시 조회했을 때 객체 동일성도 보장된다.

즉, 값만 같은 객체가 아니라 정말 같은 객체로 관리된다는 점이 중요하다.

2. 쓰기 지연

JPA는 persist()를 호출했다고 해서 바로 INSERT SQL을 실행하지 않는다.

일단 영속성 컨텍스트에 Entity를 저장하고, 실행할 SQL은 내부에 모아둔다. 그리고 flush() 또는 트랜잭션 commit 시점에 한 번에 DB로 보낸다.

ㄴ> 이걸 쓰기 지연이라고 한다.

처음에는 저장 메서드를 호출했는데 왜 DB에 바로 반영되지 않는지 헷갈릴 수 있다. 하지만 이 방식을 사용하면 트랜잭션 단위로 SQL을 모아서 처리할 수 있고, 중간에 문제가 생기면 한 번에 rollback 할 수 있다.

즉, 정합성을 유지하면서 효율적으로 처리하기 위한 방식이다.

3. 변경 감지

JPA에서 정말 신기했던 부분이 바로 변경 감지다.

JPA는 영속 상태의 Entity를 조회할 때, 처음 상태를 스냅샷처럼 저장해둔다. 그리고 트랜잭션 commit 시점에 현재 상태와 비교해서 변경된 부분이 있으면 UPDATE SQL을 자동으로 만들어준다.

-> 직접 update() 같은 메서드를 호출하지 않아도 된다.

User user = em.find(User.class, 1L);
user.setName("변경된 이름");

이렇게 값만 바꿔도, 트랜잭션이 commit 될 때 JPA가 변경을 감지해서 UPDATE SQL을 실행한다.
-> 영속성 컨텍스트가 Entity를 계속 관리하고 있기 때문이다.

🍇 Entity 상태

JPA에서 Entity는 영속성 컨텍스트와의 관계에 따라 상태가 나뉜다.

비영속(Transient)

new 연산자를 통해 인스턴스화된 Entity 객체.
아직 영속성 컨텍스트에 저장되지 않은 상태라 JPA의 관리를 받지 않음.

영속(Managed)

영속성 컨텍스트에 저장되어 JPA가 관리하는 상태

• 비영속 → 영속: persist()

준영속(Detached)

영속성 컨텍스트에 저장되어 관리되다가 분리된 상태. 더이상 변경 감지 x

• 영속 → 준영속: detach(entity), clear(), close()
• 준영속 → 영속: merge(entity)

  merge()는 기존 객체를 다시 관리하는 게 아니라, 상태를 복사한 새로운 영속 객체를 반환함.

삭제(Removed)

삭제하기로 표시된 상태. 트랜잭션 커밋 시 DELETE SQL 실행됨.

• remove(entity)

Entity 상태를 보면 결국 핵심은 하나다.
영속 상태일 때만 JPA가 Entity를 관리한다는 점이다.

즉,1차 캐시, 쓰기 지연, 변경 감지 모두 영속 상태의 Entity를 기준으로 동작한다.

🍉 Spring Boot에서의 JPA와 트랜잭션

Spring Boot에서는 JPA 사용에 필요한 설정을 많이 자동으로 처리해준다.

• application.properties 또는 application.yml에 DB 정보를 설정하면 JPA 환경이 구성됨.
• EntityManagerFactory, EntityManager도 자동 설정됨.
• @PersistenceContext를 사용하면 EntityManager를 주입받아 사용할 수 있음

@PersistenceContext
private EntityManager em;

그리고 Spring에서는 @Transactional을 사용해서 트랜잭션 범위를 지정할 수 있다. 정상 종료 시 commit, 예외 발생 시 rollback 되는 구조다.

@Transactional
public void save() {}

보통 스프링 컨테이너 환경에서는 영속성 컨텍스트가 트랜잭션 범위 안에서 함께 동작한다고 이해하면 된다.

트랜잭션 시작 → 영속성 컨텍스트 사용 → 트랜잭션 종료

이 흐름으로 생각하면 이해하기 쉽다.

그래서 변경 감지도 결국 트랜잭션이 끝나는 시점과 연결되고, 쓰기 지연도 commit 시점과 자연스럽게 연결된다.

🍑 정리

이번에 JPA를 정리하면서 느낀 건, JPA는 단순히 SQL을 대신 써주는 기술이 아니라는 점이다.

핵심은 영속성 컨텍스트를 통해 Entity를 관리한다는 것이고, 그 덕분에 같은 Entity를 캐시로 관리하고 SQL 실행을 지연시킬 수 있고 객체 값 변경만으로 UPDATE를 반영할 수 있다

즉, JPA의 편리함은 결국 영속성 컨텍스트가 Entity를 관리해주기 때문에 가능한 기능들이라고 볼 수 있다.

앞으로 JPA를 사용할 때는 단순히 save()나 find() 같은 메서드만 보는 게 아니라, 지금 이 Entity가 어떤 상태인지, 그리고 영속성 컨텍스트 안에서 관리되고 있는지를 같이 생각해야겠다고 느꼈다.