Lock

• JPA에서는 기본적으로 트랜잭션 격리 수준을 READ COMMITED로 가정. 만약에 일부 로직에 더 높은 격리 수준이 필요하다면 Lock을 사용하면 된다.
• 락은 아래의 위치에 적용가능
  • EntityManager.lock(), EntityManager.find(), EntityManager.refresh()
  • Query.setLockMode()
  • @NamedQuery

낙관적 락(Optimistic Lock)

• 낙관적 락이란?

  • ‘트랜잭션의 충돌은 거의 발생하지 않는다’고 가정
  • Commit되는 시점에 충돌여부를 확인
  • DBMS의 락 기능 대신에 JPA에서 자체적으로 제공하는 @Version 을 이용

• 두번의 갱신 분실 문제(Second Lost Updates Problem)

  

  • 과정 : 트랜잭션A, 트랜잭션B 모두 성공
  • 결과 : 최종적으로 X의 값은 2로 변경됨

  이 상황은 오류일까?아닐까?

  • A,B사용자 화면에서 모두 오류가 나지 않았기 때문에 A입장에서는 X=10으로 변경되었겠지…라고 생각함. A 입장에서는 오류라고 판단될 수 있음

  • 고려할 수 있는 방법

    1. 먼저 Commit된 것을 DB에 반영함
    2. 나중에 Commit된 것을 DB에 반영함(가장 기본 동작방식)
    3. 트랜잭션 A,B에서 Commit된 내용을 Merge해서 반영함(아주 특별한 경우만 사용)

    ⇒ JPA에서는 @Version 을 사용해서 “먼저 Commit된 것을 DB에 반영함” 전략을 구현할 수 있다.

• @Version

  • 적용가능한 필드 : Long, Integer, Short, Timestamp
  • 예시

  @Entity
  public class Board {
      @Id
      private String id;
      private String title;
      
      @Version
      private Integer version;
  		// 엔티티를 수정할 때마다 version필드값이 자동으로 증가
  		// 엔티티를 수정할 때 조회 시점의 version필드값과 수정 시점의 version필드값이 다르면 예외를 발생시킴
  }
  

  • @Version을 적용한 트랜잭션 흐름

  

• 낙관적 락 사용하기

  • NONE

    • 락 옵션을 적용하지 않고 @Version가 적용된 필드가 있을 때 자동으로 낙관적 락이 적용
    • 두번의 갱신 분실 문제를 예방
    • 테스트 시나리오(테스트 코드는 맨 아래 git url 참고)
      1. customer테이블(id,name,mileage) 에 version 필드 추가
      2. 마일리지를 -1하는 스레드를 2개 생성 후 병렬로 실행
      3. ObjectOptimisticLockingFailureException 예외가 발생하는지 확인

  • OPTIMISTIC

    • 엔티티를 조회만 할때에도 버전을 체크

    • Commit된 Transaction만 읽기 때문에 두번의 갱신 분실 문제 뿐 아니라, Dirty Read와 Non-repeatable read를 방지함

    • 사용 예시(@NamedQuery)

      @Lock(LockModeType.OPTIMISTIC)
          public CustomerEntity findFirstById(int id);
      

    • 테스트 시나리오(테스트 코드는 맨 아래 git url 참고)

      1. 스레드1(이름을 홍길동으로 변경하는 코드가 1초동안 실행됨)
      2. 스레드2(스레드 시작과 끝에 엔티티를 조회하는 코드가 3초동안 실행됨)
      3. 위 두개의 스레드를 병렬로 실행
      4. 스레드2에서 실행되는 두개의 조회쿼리 결과가 서로 다른지 확인

  • OPTIMISTIC_FORCE_INCREMENT

    • 낙관적 락을 사용하면서 버전 정보를 강제로 증가시킴

    • 강제로 버전을 증가시켜서 논리적 단위의 엔티티 묶음을 버전 관리할 수 있음

    • 사용 예시(@NamedQuery)

      @Lock(LockModeType.OPTIMISTIC_FORCE_INCREMENT)
          public CustomerEntity findFirstById(int id);
      

비관적 락(Pessimistic Lock)

• 비관적 락이란?
  • ‘트랜잭션의 충돌이 발생한다’고 가정하고 먼저 락을 검
  • DBMS의 락 기능을 사용
• 비관적 락 사용하기

  • PESSIMISTIC_WRITE

    • 다른 트랜잭션에서 읽기도 못하고 쓰기도 못함

    • 사용예시(@NamedQuery)

      @Lock(LockModeType.PESSIMISTIC_WRITE)
      @Query("select c from CustomerEntity c where c.id = :id")
      public CustomerEntity findByIdWithPessimistic(int id);
      

    • 테스트 시나리오(테스트 코드는 맨 아래 git url 참고)

      1. 스레드 5개에서동시에 마일리지 -1
      2. 예외가 발생하지 않는지 확인 + 최종 마일리지 점수가 -5되었는지 확인

  • PESSIMISTIC_READ

    • 다른 트랜잭션에서 읽기만 가능

    • 일반적으로 사용안함(데이터베이스 대부분은 방언에 의해서 PESSIMISTIC_WRITE로 동작하기 때문에)

    • 사용예시(@NamedQuery)

      @Lock(LockModeType.PESSIMISTIC_READ)
      @Query("select c from CustomerEntity c where c.id = :id")
      public CustomerEntity findByIdWithPessimistic(int id);
      

  • PESSIMISTIC_FORCE_INCREMENT

    • 다른 트랜잭션에서 읽기도 못하고 쓰기도 못함 + 비관적 락이지만 버전정보를 사용해서 엔티티의 버전관리를 함

    • 사용예시(@NamedQuery)

      @Lock(LockModeType.PESSIMISTIC_FORCE_INCREMENT)
      @Query("select c from CustomerEntity c where c.id = :id")
      public CustomerEntity findByIdWithPessimistic(int id);
      

    • 테스트 시나리오(테스트 코드는 맨 아래 git url 참고)

      1. 엔티티를 조회(LockType=none)
      2. 엔티티를 조회(LockType=PESSIMISTIC_FORCE_INCREMENT)
      3. 2번 엔티티의 version필드값이 1번 엔티티의 version값보다 1만큼 증가했는지 확인