강제 버전 증가

• 애그리것에 애그리것 루트 외에 다른 엔티티가 존재하는데 기능 실행 도중 루트가 아닌 다른 엔티티의 값만 변경된다고 하자. 이 경우 JPA는 루트 엔티티의 버전 값을 증가하지 않는다.
• 연관된 엔티티의 값이 변경된다고 해도 루트 엔티티 자체의 값은 바뀌는 것이 없으므로 루트 엔티티의 버전값을 갱신하지는 않는 것이다.
• 근데 비록 루트 엔티티의 값이 바뀌지 않았더라도 애그리것의 구성 요소중 일부값이 바뀌면 논리적으로 그 애그리것은 바뀐 것이다.
• 따라서 애그리것 내에 어떤 구성요소의 상태가 바뀌면 루트 애그리것의 버전 값을 증가해야 비 선점 잠금이 올바르게 동작한다.
• JPA는 이런 문제를 처리할 수 있도록 EntityManager find() 메서드로 엔티티를 구할 때 강제로 버전 값을 증가시키는 잠금 모드를 지원하고 있다.
• 다음은 비선점 강제 버전 증가 잠금 모드를 사용해서 엔티티를 구하는 코드의 예제이다.

		public Order findByIdOptimisticLockMode(OrderNo id) {
        Map<String, Object> hints = new HashMap<>();
        hints.put("javax.persistence.lock.timeout", 2000);
        return entityManager.find(Order.class, id, LockModeType.OPTIMISTIC_FORCE_INCREMENT, hints);
    }

• OPTIMISTIC_FORCE_INCREMENT를 사용하면 해당 엔티티의 상태가 변경되었는지 여부에 상관없이 트랜잭션 종료 시점에 버전 값 증가 처리를 한다.

오프라인 선점 잠금

• 단일 트랜잭션에서 동시에 변경을 막는 선점 잠금 방식과 달리 오프라인 선점 잠금은 여러 트랜잭션에 걸쳐 동시 변경을 막는다.

• 첫번째 트랜잭션을 시작할 때 오프라인 잠금을 선점하고, 마지막 트랜잭션에서 잠금을 해제한다.

• 잠금을 해제하기 전까지 다른 사용자는 잠금을 구할 수 없다.

• 예를 들어 수정 기능을 생각해보자, 보통 수정 기능은 두 개의 트랜잭션으로 구성된다.

• 첫번째 트랜잭션은 폼을 보여주고, 두번째 트랜잭션은 데이터를 수정한다.

• 오프라인 선점 잠금을 사용하면 폼 요청과정에서 잠금을 선점하고 수정과정에서 잠금을 해제한다.

• 이미 잠금을 선점한 상태에서 다른 사용자가 폼을 요청하면 과정 2처럼 잠금을 구할 수 없어 에러 화면을 보게 된다.