<Spring JPA> 1.5 영속성 컨텍스트

JPA 에서 가장 중요한 두가지는 JPA 이용하려 얼마나 효과적으로 데이터베이스를 객체 매핑해서 사용할 것인가와 영속성 컨텍스트를 얼마나 잘 이해하고 있는가라고 할 수 있다.

 

엔티티매니저팩토리는 요청이 올때마다 엔티티 매니저를 생성하여 커넥션 풀에서 커넥션을 꺼내 사용하고 사라진다.

 

영속성이라는 개념은 엔티티를 영구 저장하는 환경이라고 보면 된다. 논리적인 개념이고 눈에 보이지 않는 장소이다. 엔티티 매니저를 통해서 영속성 컨텍스트에 접근할 수 있다.

 

J2SE (Standard Edition, 일반 자바 프로그램 개발을 위한 용도로 이용되는 개발도구이며 각종 자료구조, 기본 유틸리티, 스윙이나 AWT와 같은 GUI도구등의 기본기능을 포함하고 있다) 에서는 엔티티 매니저와 영속성 컨텍스트가 1:1

 

J2EE (Enterprise Edition, 엔터프라이즈 환경을 위한 도구로 EJB, JSP, Servlet, JNDI같은 기능을 지원하며 웹 애플리케이션 서버를 이용하는 프로그램 개발시 많이 사용한다.) 와 스프링 같은 프레임워크에서는 엔티티 매니저와 영속성 컨텍스트가 N:1 이다.

 

엔티티의 생명주기, 또는 상태로는 4가지가 있다. 비영속, 영속, 준영속, 삭제.

비영속과 준영속이 말이 조금 애매모호하다. 구분을 짓자면 비영속은 원래 속하지 않았던 아예 관계없는, 

준영속은 한번 속했다가 분리된 상태다.

 

준프로 운동선수 같은 느낌으로 '준' 이라는 느낌을 이해하면 ... 더 혼동될까? 모르겠다. 알아서 파악하자.

 

객체를 생성한 상태. 이 상태는 아예 영속상태로 들어가지 않았으므로 비영속 상태라고 할 수 있다.

 

영속상태는 객체를 생성하고 persist 를 통해서 영속상태로 들어간 상태를 뜻한다.

 

준영속과 삭제도 구분을 잘해야한다. 삭제는 정말 영속상태에서 삭제하라고 명령을 내린 것이고 이를 커밋한 경우 디비에 삭제 쿼리가 날라간다. 준영속은 영속상태에서 분리해낸 것이고, 영속 상태가 아니게 만든다는 것 뿐이다.

 

영속성 컨텍스트를 그럼 왜 쓰는 것일까?

첫번째로 1차 캐시를 말할 수 있지만, 사실 큰 이득은 없다고 한다. 한 트랜잭션 내에서만 성립되기 때문에 이득이 되기 힘들다.

두번째로 동일성, equals 를 했을 때 같다. 그다음부터 나열하면 트랜잭션을 지원하는 쓰기 지연, 변경 감지, 지연 로딩이 있다.

 

엔티티를 조회한다면 처음으로 영속성 컨텍스트의 1차 캐시를 조회한다. 있으면 그것을 반환하고 없으면 디비에 조회 쿼리를 날려 정보를 가져온다. 그리고 1차 캐시에 저장함과 동시에 이를 반환해준다. 엔티티 매니저는 트랜잭션이 종료될 때까지 쿼리를 보내지 않는다. 영속성 컨텍스트에서 그것을 관리하고 커밋하는 순간 종합하여 필요한 부분만 쿼리를 보낸다.

 

영속성 컨텍스트에서는 쓰기 지연 SQL 저장소와 1차 캐시 저장소, 두가지 저장소가 있다고 보면 편하다. 물론 자세하게 어떻게 생긴지는 모른다. 하지만 사용하는 입장에서 두 가지가 있다고 생각하자.