일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- 매핑정보가없는필드
- Git
- 데이터베이스 방언
- 자바ORM표준프로그래밍
- 멱등활용
- hibernate.dialect
- @Table
- 네이버로그인API
- SpringBoot
- gitreset
- DB방언
- org.apache.ibatis.binding.BindingException
- 캐쉬가능
- fixedDelay
- Invalid bound statement (not found)
- http
- KAKAOLOGINAPI
- HTTPMESSAGE
- 네이버 연결된 서비스
- JPA
- anyMatch
- HTTP3
- ERROR TYPE : org.apache.ibatis.binding.BindingException
- gitrevert
- 무상태프로토콜
- 김영한JPA
- Transaction not successfully started
- @Entity
- RFC723x
- initialDelay
Archives
- Today
- Total
twocowsong
영속성 컨텍스트 - 트랜잭션 본문
깃허브 정리 URL : https://github.com/sWineTake/jpa.git
엔티티 등록
엔티티 매니저를 사용해서 엔티티를 영속성 컨텍스트에 등록해봅시다.
EntityManager em = emf.createEntityManager();
EntityTransaction tx = em.getTransaction();
// 엔티티 매니저는 데이터 변경 시 트랜잭션을 실행해야 합니다.
tx.begin(); // 트랜잭션 시작
em.persist(memberA);
em.persist(memberB);
// 여기까지 INSERT SQL을 DB에 보내지 않습니다.
// 커밋하는 순간 DB에 INSERT SQL을 보냅니다.
tx.commit();
엔티티 매니저는 트랜잭션을 커밋하기 직전까지 DB에 엔티티를 저장하지않고
내부 쿼리 저장소에 INSERT SQL를 저장해둡니다.
그리고 트랜잭션을 커밋할 때 모아둔 쿼리를 DB에 보내는데 이것을 트랜잭션을 지원하는 쓰기 지연 이라 합니다.
트랜잭션을 커밋하면 엔티티 매니저는 우선 영속성 컨텍스트를 플러시 합니다.
플러시는 영속성 컨텍스트에 변경 내용을 DB에 동기화하는 작업인데
이때 등록, 수정, 삭제한 엔티티를 DB에 반영합니다.
좀더 구체적으로 이야기하면 쓰기 지연 SQL 저장소에 모인 쿼리를 DB에 보냅니다.
이렇게 영속성 컨텍스트의 변경 내용을 DB에 동기화 후 실제 DB트랜잭션을 커밋합니다.
트랜잭션을 지원하는 쓰기 지연이 가능한 이유
다음 로직을 2가지 경우로 생각해봅시다.
begin(); // 트랜잭션 시작
save(A);
save(B);
save(C);
commit(); // 트랜잭션 커밋
위 내용은 save(A), save(B), save(C) 모두 트랜잭션을 커밋하면 함께 저장되고 롤백하면 함께 저장되지 않습니다.
등록 쿼리를 DB에 전달해도 트랜잭션을 커밋하지 않으면 저장되지않습니다.
어떻게든 커밋 직전에만 DB에 SQL을 전달하면 됩니다. 이것이 트랜잭션을 지원하는 쓰기 지연이 가능한 이유입니다.
이 기능을 잘 활용하면 모아둔 등록 쿼리를 DB에 한번에 전달해서 성능을 최적화할 수 있습니다.
'IT > JPA' 카테고리의 다른 글
엔티티 수정 - 2 (0) | 2022.05.05 |
---|---|
엔티티 수정 - 1 (0) | 2022.05.04 |
엔티티 컨텍스트의 1차 캐시 (0) | 2022.05.02 |
영속성 컨텍스트의 특징 (0) | 2022.05.01 |
엔티티의 생명주기 (0) | 2022.05.01 |