7. 트랜잭션

트랜잭션 범위의 영속성 컨텍스트

# 스프링 컨테이너의 기본 전략

• 동일 트랜잭션엔 동일 영속성 컨텍스트를 사용한다.
• 트랜잭션이 다르면 영속성 컨텍스트도 다르다.

fastcampus.co.kr/courses/204729/clips/

# 트랜잭션 종료 이후 지연로딩 속성에 접근할 경우?

 

  (1) 뷰가 필요한 엔티티를 미리 로딩하는 방법

• 글로벌 페치 전략 수정
  • 사용하지 않는 엔티티를 로딩
  • N + 1 문제 발생
• JPQL 페치 조인
  • 무분별한 사용 시 리포지토리 메서드가 증가한다. →프리젠테이션 계층이 데이터 접근 계층을 침범한다.
• 강제 초기화
  • 프록시 초기화 역할을 서비스 계층이 담당하면 뷰가 필요한 엔티티에 따라 서비스 계층의 로직을 변경해야 한다. →프리젠테이션 계층이 서비스 계층을 침범한다.
• FACADE 계층 추가

  (2) OSIV 를 사용하여 엔티티를 항상 영속 상태로 유지하는 방법

• Open Session In View : 영속성 컨텍스트를 뷰까지 열어둔다.
  • 클라이언트의 요청이 들어올 때 영속성 컨텍스트를 생성해서 요청이 끝날때까지 컨텍스트를 유지한다.
  • 엔티티 수정은 트랜잭션이 있는 계층에서만 동작한다.

# 롤백 시 주의사항 - 트랜잭션 종료 이후 지연로딩 속성에 접근할 경우?

• 트랜잭션 롤백은 DB의 반영사항만을 롤백하는 것이다. 수정한 엔티티까지 원상태로 복구해주지 않는다.
• 트랜잭션이 롤백된 경우 영속성 컨텍스트를 그대로 사용하는 것은 위험하다. 새로운 영속성 컨텍스트를 생성하거나 EntityManager.clear() 를 호출하여 초기화 한다. 

# 트랜잭션은 원자성, 일관성, 격리성, 지속성을 보장해야한다.

• 낙관적 락 : 트랜잭션 대부분 충돌이 발생하지 않는다고 가정하고 락을 사용하는 것
• 비관적 락 : 트랜잭션 대부분 충돌이 발생한다고 가정하고 락을 사용하는 것

※ 락을 잡고 데이터를 수정했을 경우 생기는 문제점? "두 번 갱신 문제"

 

→ 해결방법

 

  (1) 마지막 커밋만 인정  

  (2) 최초 커밋만 인정 

  (3) 갱신 내용 병함

  (4) @Version 컬럼

  (5) JPA 락 사용

 

※ N+1 문제는 JPA 사용 시 성능 저하에 가장 큰 요인 중 하나이므로 주의를 요한다.

→ 페치 조인을 사용함으로써 해결한다.

 

 

출처 : fastcampus.co.kr/courses/204729/clips/