JPA LOCK

락모드	타입	설명
낙관적락	OPTIMISTIC	낙관적락 사용
낙관적락	OPTIMISTIC_FORCE_INCREMENT	낙관적 락 + 버전정보를 강제로 증가한다.
비관적락	PESSIMISTIC_READ	비관적락 ,읽기 락을  사용한다.
비관적락	PESSIMISTIC_WRITE	비관적 락, 쓰기 락을 사용한다.
비관적락	PESSIMISTIC_FORCE_INCREMENT	비관적락 + 버전정보를 강제로 증가한다.
기타	NONE	락을 걸지않는다.
기타	READ	JPA1.0 호환 기능이다. OPTIMISTIC과 같으 OPTIMISTIC을 사용하면 된다.
기타	WRITE	JPA1.0 호환 기능이다. OPTIMISTIC_FORCE_IMCREMENT와 같다

사용예.

1)

Board board = em.find(Board.class, id , LockModeType.OPTIMISTIC);  ::::::::: 조회시 락을 걸수있다.

2)

Board board = em.find(Board.class, id);  

em.lock(board,LockModeType.OPTIMISTIC); ::::::::: 필요시 락을 걸수도있다.

낙관적락

낙관적 락은 트랜잭션 대부분은 충돌이 발생하지 않는다고 낙관적으로 가정하는방법이다. 이것은 데이터베이스가 제공하는 락 기능을 사용하는것이 아니라 JPA가 제공하는 버전 관리 기능을 사용한다. 애플리케이션이 제공하는락이다. 트랜잭션을 커밋하기 전까지는 트랜잭션의 충돌을 알수없다는 특징이있다.

비관적락

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

VERSION 관리

@Entity

public class Board{

@Id

private String id;

private Stirng title;

@Version

Integer version;

}

버전관리를 시작하면 엔티티를 수정할때마다 버전이 하나씩 자동으로 증가한다.

그리고 엔티티를 수정할때 조회시점의 버전과 수정시점이의 버전이 다르면 예외가 발생한다.

예를 들면 트랜잭션 1이 조회한 엔티티를 수정하고있는데 트랜잭션 2에서 같은 엔티티를 수정하고 커밋해서 버전이 증가해버리면 트랜잭션 1이 커밋할때 버전정보가 다르므로 예외가 발생한다.

버전정보를 사용하면 최초커밋만 인정하기가 적용된다.