영속성 관리 개념
엔티티 매니저, 엔티티 매니저 팩토리?
Entity Manager - 엔티티를 C,R,U,D 등 관련된 것을 모두 관리한다. 즉 엔티티를 관리하는 관리자
EntityManager Factory? - 번역하면 엔티티 매니저를 만드는 공장이다.
여기서 팩토리는 팩토리 메서드 패턴이다. 팩토리 메소드 패턴은 부모 클래스에 알려지지 않은 구체 클래스를 생성하는 패턴이다. 엔티티 매니저 팩토리를 만드는 비용은 상당히 많이 든다. 그래서 하나만 만들어서 전체의 애플리케이션에서 공유하는 방향으로 사용한다.
엔티티 매니저 팩토리는 여러 스레드가 동시에 엔티티 매니저 팩토리에 접근해도 괜찮다 = 여러 스레드가 공유할 수 있다.
하지만 엔티티 매니저는 여러 스레드가 동시에 접근할 시 동시성 문제가 생겨서 공유하면 안됨
영속성 컨텍스트?
엔티티를 영구 저장하는 환경이라는 의미를 가지고 있으며 위에서 언급한 엔티티 매니저가 엔티티에 접근할 때 영속성 컨텍스트에서 관리한다. 영속성 컨텍스트는 논리적인 개념이라서 보이지는 않지만 대충 엔티티 매니저를 생성할 때 하나가 만들어진다고 보면 된다.
영속성 컨텍스트는 하나의 엔티티 매니저에 하나의 영속성 컨텍스트가 만들어진다고 생각하자
엔티티의 생명 주기?
4가지의 상태가 존재한다.
비영속(new/transient) : 영속성 컨텍스트와 전혀 관계가 없는 상태
단순하게 객체를 만들었을 때이기 때문에 DB에는 저장하지 않았으며 따라서 영속성 컨텍스트와도 관련이 없다
@Transient라는 애노테이션도 있다! → 이걸 사용하면 엔티티를 저장하는 과정에서 원하는 컬럼은 저장하지 않고 객체에서만 사용할 수 있다.
영속(managed) : 영속성 컨텍스트에 의해 관리되고 있는 상태
객체를 엔티티 매니저를 통해서 영속성 컨텍스트에 저장한 상태를 의미한다.
entitymanager.persist(엔티티)을 통해서 영속 시키고 entitymanager.find()나 JPQL을 사용해서 영속성 컨텍스트가 관리하고 있는 엔티티에 접근할 수 있다.
준영속(detached) : 영속성 컨텍스트에 저장되었다가 분리된 상태
영속성 컨텍스트가 엔티티를 더 이상 관리하지 않는다면 그것이 바로 준 영속 상태이다.
entitymanager.detach(엔티티)을 통해서 준영속 상태로 바꿔줄 수 있다. = 더 이상 관리하지 않을 수 있음
이외에도 entitymanager.close()을 통해서 영속성 컨텍스트를 종료하거나 entitymanager.clear()을 통해서 영속성 컨텍스트를 초기화하면 해당 영속성 컨텍스트에서 관리하고 있던 모든 엔티티들은 준영속 상태로 변경된다.
삭제(removed) : 삭제된 상태
그냥 엔티티를 영속성 컨텍스트에서, 데이터 베이스에서 삭제하는 역할
entitymanager.remove()을 통해서 삭제
영속성 컨텍스트의 특징
식별자
영속성 컨텍스트에 엔티티를 영속시킬 때, 영속성 컨텍스트는 엔티티를 식별자 값으로 구분하게 된다. 이 식별자 값은 @Id 애노테이션을 통해서 구분하게 된다.
따라서 영속 상태는 식별자 값이 반드시 있어야 한다. 만약 식별자 값이 없다면 예외 발생
영속성 컨텍스트와 데이터베이스에 저장 시점
JPA는 트랜잭션을 커밋하는 순간에 영속성 컨텍스트에 새롭게 들어온 엔티티를 데이터 베이스에 반영하게 되고 이 현상을 flush라고 한다.
관리의 장점
1차 캐시, 동일성 보장, 트랜잭션을 지원하는 쓰기 지연, 변경 감지, 지연 로딩와 같은 기능을 지원
엔티티 조회
엔티티 컨텍스트의 내부에는 캐시 시스템이 존재하고 그것을 1차 캐시라고 한다. 그리고 엔티티 매니저에 저장되는 모든 엔티티는 1차 캐시에 저장되게 된다. 구성 자체는 맵이라고 생각하면 된다. 식별자-엔티티 이런 식으로 저장되었다고 생각하면 된다.
persist 함수를 사용하게 되면 맵 방식으로 1차 캐시에 저장하고 아직은 데이터베이스에 저장되지 않은 상황이다.
find 함수를 사용하게 되면 맵 방식으로 1차 캐시에서 우선적으로 식별자 값으로 엔티티를 찾고 1차 캐시에서 찾지 못했다면 데이터베이스에서 찾는다.
만약 1차 캐시에서 엔티티를 찾지 못해서 데이터베이스에서 조회하게 되었다면 영속성 컨텍스트 입장에서는 데이터 베이스에서 조회한 엔티티를 1차 캐시에 생성하고 나서 엔티티를 뱉어준다.
1차 캐시에서 저장하는 엔티티 인스턴스와 데이터 베이스에서 저장하는 엔티티 인스턴스는 동일하다. 그 의미는 객체가 같은 뿐만 아니라 그 객체가 가리키는 값까지 같다는 의미이고 완전히 같은 값을 의미한다.
자바 객체 동일성, 동등성 → 객체의 equals 함수를 사용해서 객체의 해쉬값 까지 비교하는 방식이다.
엔티티 등록
엔티티 매니저는 트랜잭션을 커밋하기 전까지는 내부 쿼리 저장소에 쿼리들을 모아둔다. 그리고 커밋할 때 저장해둔 내부 쿼리 저장소에 있는 쿼리들을 한꺼번에 보낸다. 이렇게 한꺼번에 내부 쿼리 저장소에서 모아둔 쿼리들을 트랜잭션 커밋 시 보내는 것을 쓰기 지연 이라고 한다.
위처럼 계속해서 persist을 통해서 엔티티를 저장할 때 쿼리문도 저장해뒀다가
commit()이 왔을 때 한꺼번에 flush()을 통해서 보내준다.
엔티티 수정
JPA로 엔티티를 수정할 때는 단순하게 엔티티를 조회해서 데이터만 변경하면 된다. 따로 update를 치지 않아도 그냥 영속성 컨텍스트에 가져와진 객체를 수정하는 것만으로도 알아서 데이터베이스에 수정이 된다. 그리고 이러한 기능을 변경 감지라고 한다.
흐름을 보면
스냅샷? - JPA는 엔티티를 영속성 컨텍스트에 저장할 떄 가장 최초 상태를 복사하는데 이 복사된 것을 스냅샷이라고 함
flush()함수로 업데이트가 들어오면
엔티티와 스냅샷을 비교해서 변경된걸 찾고
수정 쿼리를 만들어서 쓰기 지연 저장소에 저장
쓰기 지연 저장소에 있는 쿼리를 데이터 베이스에 보냄
트랜잭션을 커밋
변경 감지의 특징은 아무런 엔티티나 모두 다 되는 게 아니라 오직 엔티티 매니저가 관리하고 있는 상태인 영속상태인 엔티티에만 적용이 가능하다!
변경 감지를 통해서 생성된 수정 SQL은 엔티티의 수정되는 부분만 수정하는 것이 아니라 엔티티의 모든 필드를 업데이트 친다 → 왜일까?
이유는 2가지
모든 필드를 사용하면 수정 쿼리가 항상 같기 때문에 애플리케이션 로딩 시점에 수정 쿼리를 미리 생성해두고 재사용이 가능하다.
데이터 베이스에 동일한 쿼리를 보내면 데이터베이스는 이전에 한 번 파싱된 쿼리를 재사용할 수 있다.
엔티티 삭제
엔티티를 삭제하기 위해서는 일단 조회를 통해서 확인을 하게 되고 remove()을 통해서 삭제를 하게 되는데 remove() 호출 → 삭제 쿼리를 지연 쓰기 저장소에 저장, 1차 캐시에서는 엔티티 삭제 → 커밋 시, flush 호출 → 데이터 베이스에 삭제 쿼리 전달
-그럴일은 없겠지만 remove를 통해서 삭제한 엔티티는 다시 재사용하지말자?
플러시
flush()는 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영해주는 역할을 수행한다.
이것의 의미는 영속성 컨텍스트에 있는 변경 내용을 지우고 데이터베이스에 반영한다는 의미가 아니다!!! → 변경 사항이 있는 영속성 컨텍스트와 데이터베이스를 동기화 시키는 의미
동작순서
변경 감지를 통해서 영속성 컨텍스트에 있는 모든 엔티티를 스냅샷과 비교해서 수정된 엔티티를 찾고, 수정된 엔티티에 대한 수정 쿼리를 만들어서 쓰기 지연 저장소에 저장
쓰기 지연 저장소에서 SQL문을 데이터베이스에 전송
flush하는 방법
직접 entitymanager.flush()을 호출
테스트하는 과정이나 특별한 겨우가 아니면 사용하지 않는다.
트랜잭션 커밋 시 flush()를 자동으로 호출
데이터 베이스의 수정 사항을 SQL을 통해서 전달하지 않고 그냥 트랜잭션만 커밋하면 데이터 베이스에 수정 사항이 적용되지 않는다. 그래서 트랜잭션을 커밋하기 전, flush()을 호출해서 데이터 베이스에 적용시켜 하는데, JPA에서는 이런 사항을 미리 처리해주기 위해서 자동으로 트랜잭션을 커밋하기 전에 flush()을 호출하게 되어 있다.
JPQL 쿼리 실행 시 flush()를 자동으로 호출
flush 옵션
flush를 하는데 옵션을 수동으로 지정할 수 있는데, javax.persistence.FlushModeType을 사용해서 지정해준다.
entitymanager.setFlushMode(타입)
FlushModeType.AUTO : 커밋이나 쿼리를 실행할 때 flush해줌 → default
FlushModeType.COMMIT : 커밋할 때만 flush → 최적화된 성능을 제공하기 위해서 사용
준영속
준영속 상태 이라는 의미는 영속되어 있었던 엔티티가 영속성 컨텍스트에서 분리(detached)되어 더 이상 영속성 컨텍스트의 기능을 사용하지 못하는 상태를 의미
여기서 영속성 컨텍스트의 기능이란 쓰기 지연 저장소나 1차 캐시에서 더 이상 준영속 엔티티를 저장하고 있지 않겠다는 의미
준영속 상태로 만드는 방법
entitymanager.detach(엔티티) : 파라미터로 넣어준 엔티티만 준영속 상태로 바꿈
entitymanager.clear() : 영속성 컨텍스트를 완전하게 초기화
entitymanager.close() : 영속성 컨텍스트를 종료
clear() 와 close()의 차이를 생각해보면 비슷하다고 생각했지만 조금은 다르다
clear()를 통해서 여러가지로 쌓여있었던 엔티티들을 한 번 정리하고 사용하는 것이 가능
close()은 사용하던 영속성 컨텍스트를 한 번 지운다는 것
그래서 준영속 상태가 되면 어떻다는거지?
거의 비영속 상태에 가깝다
일단은 중요한 영속성 컨텍스트를 사용할 수 없기 때문에 필요한 기능들을 사용할 수 없다
식별자 값을 가지고 있다
준영속이기 때문에 한번 영속되었던 적이 있기 때문에 영속 상태였을 때 가지고 있었던 식별자 값을 그대로 가지고 있다
지연 로딩을 할 수 없다
(fetchType?에서 있는 lazy타입인데, 이후에 한 번 더 나오면 정리하자)
지연 로딩은 실제 객체 대신 프록시 객체를 로딩하고 해당 객체를 실제 사용할 때 영속성 컨텍스트를 통해 데이터를 불러오는 방식인데, 애초에 프록시 객체를 가져오는 것부터 틀렸기 떄문에 불가능하다
그럼 준영속 상태에서 다시 영속상태로 변경하는 방법은?
병합(merge)
entitymanager.merge(엔티티) 이렇게 사용하고 사용하면 기존의 준영속 상태의 엔티티의 정보를 가지고 다시 새로운 영속 상태의 엔티티를 반환해준다.
다시 병합할때 위에서 언급했던 식별자 값을 아직도 가지고 있는게 사용되게 되는데,
실행순서를보자
merge(엔티티) 실행
준영속 엔티티의 기존의 식별자 값을 가지고 1차 캐시를 뒤진다
1차 캐시에서 찾지 못했다면 데이터 베이스에서 찾는다
찾은게 있다면 그 엔티티에 엔티티 값을 채워 넣는다.
없다면 새로운 엔티티를 만들어서 병합
자 그럼 결국 값으로 넘어온 엔티티를 1차 캐시와 데이터베이스에서 찾아보고 없으면 새로운 엔티티를 만들어서 생성 있으면 있던 값에 채워넣는다.
이렇게 보니까 merge할 때는 준영속이나 비영속이나 상관없다는 것!
있는 값이라면 update 쿼리를 실행하고 없는 값이라면 save 쿼리를 실행하는구나
Last updated
Was this helpful?
