반응형

영속성 컨텍스트란 

쉽게 말해 엔티티를 영구 저장하는 환경이다.

 

엔티티 매니저를 통해 영속성 컨텍스트에 접근한다.

1차 캐시

영속 컨텍스트 (entityManager) 사실은 같지는 않지만 우선 비슷하다고 생각하자

이러한 코드로 member 엔티티를 영속을 하면 DB에 저장되는 것이 아닌 1차 캐시에 저장이 되게 된다.

나중에 em.find을 통해 member 클래스안에서 "고라니" 를 조회할때는 DB에 접근해서 

데이터를 가져오는 것이 아니고 1차 캐시에 저장되어있는 엔티티에 접근해서 데이터를 가져와서 더 빠르게 처리가 가능하다.

 

 

만약 조회했는데 1차 캐시에 값이 없다면 그 이후 DB에 조회를 하게 되고 

값이 있는 데이터라면 1차 캐시에 저장을 하고 반환을 하게 된다.

쉽게 중간에 1차캐시에 저장해서 속도를 더 빠르게 만든다.

 

영속 엔티티의 동일성 보장

 

엔티티의 서로 다른 두 인스턴스가 DB테이블에서 동일한 행을 나타내는 경우 Java에 equals()메소드와 동일한 형태로 되어야 한다.

 

트랜잭션을 지원하는 쓰기 지연 (transactional write-behind)

 

memberA, memberB를 영속석 컨테스트에 저장하는 과정이다.

사진 처럼 member을 저장할때는 두개로 나뉘게 되는데 

1. 1차캐시에 저장

2. INSERT SQL생성이 된다.

여기서 중요한것은 INSERT SQL을 생성해서 쓰기 지연 저장소에 저장하는 것인데

이부분에서 버퍼링 , 즉 데이터를 한번에 모아서 tx.commit() 시점에 처리하기 때문에 효율적으로 데이터를 처리가 가능해진다.

 

변경 감지(Dirty Checking)

말그대로 변경을 감지하는 것이다.

 

영속성 엔티티를 조회하고 조회한 값을 수정할 때 값을 바꿨으니 DB에 값을 저장하기 위해 UPDATE 문을 보내야 하지 않을까 ?

생각이 든다.

사실은 필요가 없다.

 

값을 변경하는데 불구하고 업데이트 문을 DB에 날리지 않아도 되는 이유는 

 

flush() : 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영한다.

데이터가 들어오면 엔티티는 처음에 가지고 있던 스냅샷과 현재 들어온 Entity를 비교하고

달라진 부분이 있다면 UPDATE SQL 생성하고 이 쿼리를 DB에 반영하고 commit하게 된다.

 

따라서 데이터를 변경했을때는 em.persist()를 사용할 필요가 없다.

반응형

+ Recent posts