JPA 낙관적 락과 비관적 락

JPA 낙관적 락

• JPA에서 Application Level에서의 Lock
• JPA의 버전 관리 기능을 사용함
• 낙관적 락은 트랜잭션을 커밋하기 전까지는 트랜잭션의 충돌을 알 수 없음

비관적 락

• 트랜잭션의 충돌이 발생한다고 가정하고 우선 락을 걸고 보는 방법
• 데이터베이스가 제공하는 lock기능을 사용함
• 대표적으로 select for update 구문이 존재

트랜잭션의 범위를 넘어서는 문제도 존재
-> 두번 갱신 내역 분실 문제

JPA에서 낙관적 락 사용을 위해선 무엇을 알아야하는가?

• @Version: 낙관적 락 사용을 위한 annotation
• JPA Lock: 옵션을 통한 락 세밀 제어
  - option: NONE, OPTIMISTIC, OPTINISTIC_FORCE_INCREMENT(Aggregate root)

jpa를 사용할 때 추천하는 전략은 read committed 트랜잭션 격리 수준 + 낙관적 버전 관리임

JPA 비관적 락을 사용하기 위해서는 무엇을 알아야 하는가?

• 데이터베이스에 트랙잭션 락 메커니즘에 의존하는 방법
• 엔티티, 스칼라 타입을 조회할 때도 사용할 수 있고, 데이터를 수정하는 즉시 트랜잭션 충돌을 확인할 수 있음
  옵션
  - PESSIMISTIC_WRITE: 비관적 락의 일반적 옵션을 뜻함(쓰기 락)
  - PESSIMISTIC_READ: 반복 읽기만하고 수정하지 않는 용도로 락을 걸 때 사용(잘사용하지 않음)
  - PESSINISTIC_FORCE_INCREMENT: 비관적 락중 유일하게 버전 정보를 사용함
  

2차 캐시

사용하는 이유: 네트워크를 통한 DB 접근보다, application server 내 메모리에 접근하는 시간이 훨씬 효율적임. 하지만 1차 캐시만으로는 제약사항이 존재

1차 캐시: 영속성 컨텍스트 내 엔티티 저장소, 1차 캐시의 유효는 트랙잭션 시작과 종료에 한정적
OSIV를 사용하더라도, 클라이언트 요청 및 응답에 한정적

2차 캐시: 애플리케이션에서 공유하는 캐시를 JPA는 공유 캐시라함. 이것을 2차 캐시라 말함

Persistence Context(1차 캐시) <-> (2차 캐시) <-> Database

JPA에서 2차 캐시기능을 사용하려면 무엇을 알아야 하는가?

• 캐시모드 설정
  - 엔티티에 설정을 위해서는 shared-cache-mode property를 설정함

  • 옵션 값에 따라 각 엔티티 별 혹은 모든 엔티티에 캐시 모드를 설정할 수 있음

• 캐시조회, 저장방식 설정
  - 캐시를 무시하고 데이터베이스를 직접 조회하거나 캐시를 갱신하려면 캐시 조회 모드와 캐시 보관 모드를 사용하면 됨

• JPA 캐시 관리 API
  - EntityManagerFactory에서 얻을 수 있는 캐시 객체를 이용