JPA에서 DB 동시성을 제어하는 방법

JPA는 직접 동시성을 해결하기 보다는 DB의 동시성 제어 방법을 활용하는 방향으로 기능을 제공한다.

 

낙관적 잠금 (비선점 잠금)

트랜잭션 간에 충돌이 발생하지 않을 것이라고 기본적으로 가정하고 트랜잭션을 진행하는 방법을 말한다.

 

@Entity
public class Entity {
    @Id
    private Long id;
 
    @Version
    //int, Integer, long, Long, short, Short, java.sql.Timestamp 등과 같은 Type 사용 가능
    private Integer version;
}

 

@Version이 적용된 필드가 존재하면 암시적으로 낙관적 잠금이 적용된다.

 

만약 Version 정보가 다른 경우 (dirty read가 발생한 경우) OptimisticLockException이 발생하고 트랜잭션은 롤백 처리된다.

해당 예외를 명시적으로 처리해주어야 한다.

 

장점

Row나 Table에 어떠한 lock도 걸지 않기 때문에 lock이 걸려야 하는 비관적 잠금에 비해 성능이 좋다.

 

단점

failure, exception에 대해 어떻게 대처할 것인지 설정을 해두어야 한다.

팀원간의 낙관적 잠금을 사용할 것이라는 상호 합의가 되어있지 않은 경우 문제가 발생할 수 있다.

 

사용 예시

업데이트가 거의 일어나지 않거나 사용량 자체가 적어 충돌이 거의 발생하지 않을 것이라고 생각되거나 read-heavy한 경우 비관적 잠금보다 더 좋은 성능을 가지는 낙관적 잠금이 선호될 수 있다.

 

비관적 잠금 (선점 잠금)

기본적으로 충돌이 발생할 것이라고 가정하므로 트랜잭션에서 접근하고자 하는 table이나 row에 lock을 걸고 작업을 진행하는 기법을 말한다.

 

비관적 잠금에는 PESSIMISTIC_READ, PESSIMISTIC_WRITE 옵션이 존재한다. #

PESSIMISTIC_READ는 shared(read) lock을 의미하며 read 도중에 데이터가 update가 되지 않음을 보장받고 싶을 때 사용한다. (repeatable-read)

다른 트랜잭션이 해당 데이터에 아무 제한없이 접근할 수 있다.

 

PESSIMISTIC_WRITE는 exclusive(write) lock이며 update하는 트랜잭션에서 lock이 걸린다.

엔티티의 데이터를 update하는 도중에 serialization을 설정한다.

동시다발적인 update 트랜잭션이 발생하여 매우 높은 확률로 failure가 발생할 수 있는 지점에 해당 설정을 사용할 수 있다.

 

비관적 잠금을 이용하는 경우 Deadlock이 발생할 수 있다.

 

 

장점

충돌이 발생할 것이라고 가정하고 시작하므로 낙관적 잠금보다 더 높은 integrity를 보장한다.

 

단점

한 스레드의 lock에 의해 다른 스레드에선 해당 데이터에 접근이 제한되기에 그로 인한 성능 저하가 발생한다.

Deadlock이 발생할 수 있다.

 

사용 예시

충돌이 예상되는 모든 지점에서 사용 가능하며 낙관적 잠금이 필요한 경우를 제외한 모든 경우.

 

레퍼런스

https://velog.io/@lsb156/JPA-Optimistic-Lock-Pessimistic-Lock

JPA의 낙관적 잠금(Optimistic Lock), 비관적 잠금(Pessimistic Lock)

 

https://stackoverflow.com/questions/129329/optimistic-vs-pessimistic-locking

Optimistic vs. Pessimistic locking