비관적 락(Pessimistic Locking) :: DB에서 처리
비관적 락은 동시성 문제를 해결하기 위해 데이터를 수정하려는 트랜잭션이 해당 데이터에 먼저 락을 걸어 다른 트랜잭션이 접근하지 못하게 하는 방식이다. 이러한 방식은 동시성 문제를 피하기 위해 트랜잭션 충돌이 발생할 것이라 가정하고 미리 락을 걸어 동시 접근을 차단한다. 비관적 락은 대기 시간이 길어질 수 있으며, 데드락(Deadlock) 문제에 대한 처리가 필요하다.
비관적 락은 사용자들이 같은 데이터를 동시에 수정할 것이라고 예상될 때 사용
낙관적 락(Optimistic Locking) :: APP부분에서 처리
낙관적 락은 동시성 문제가 발생할 가능성이 낮다고 가정하고, 여러 트랜잭션이 동시에 데이터에 접근할 수 있도록 허용한다. 하지만 실제로 데이터를 변경할 때 충돌이 발생하면, 해당 트랜잭션은 롤백되고 에러를 반환한다. 낙관적 락은 충돌 발생 시점에만 데이터에 대한 동시성 제어를 수행하기 때문에, 성능상 이점이 있다. 일반적으로 동시성 충돌이 자주 발생하지 않는 경우에 적합한 방식이다. 특징은 DB에서 제공해주는 락이 아닌 Application Level에서 잡아주는 락이다.
낙관적 락은 사용자들이 같은 데이터를 동시에 수정이 빈번하지 않을 것이라고 예상될 때 사용
(자원에 락을 걸지 않고, 동시성 문제가 발생하면 그때 처리 한다)
요약하면, 비관적 락은 동시성 충돌이 발생할 것으로 가정하고 미리 락을 걸어 동시 접근을 차단하는 방식이며, 낙관적 락은 동시성 충돌이 거의 발생하지 않을 것으로 가정하고 동시 접근을 허용하되, 충돌 발생 시점에 처리하는 방식이다.
우리 프로젝트에서는 충돌 가능성이 상당히 낮을 것이라고 판단되었다. 해당 서비스는 금전적인 거래가 아닌 요청에 대한 처리이기 때문에 중요도가 크지 않다는 점이다. 또한, 트래픽이나 서비스의 크기 등을 고려해봤을 때, 충돌이 발생할 가능성이 매우 적다. 그렇기 때문에 어플리케이션 레벨에서 락을 처리하고 만약 충돌이 발생할 경우 처리를 하는 로직을 작성하면 된다.
# 비관적 락을 사용하면 좋은 경우
- 데이터의 무결성이 중요하다.
- 데이터 충돌이 많이 발생할 것으로 예상된다.
# 낙관적 락을 사용하면 좋은 경우
- 데이터 충돌이 자주 일어나지 않을 것이라고 예상된다.
- 조회 작업이 많아 동시 접근 성능이 중요하다.
'Java Spring Boot' 카테고리의 다른 글
| SpringBoot) Service interface와 Serviceimpl 구현체로 나눠야 될까? (0) | 2025.02.16 |
|---|---|
| front에서 back으로 body값 전달 시(List 형태인 경우) (0) | 2024.11.21 |
| @OneToMany @ManyToOne (0) | 2024.10.18 |
| terminal 단축키(mac os) / zsh, oh-my-zsh, iterm2 (0) | 2024.06.24 |
| java) stream(스트림) (0) | 2024.06.06 |
