1. 부정적 락과 분삭락
1)Pessimistic_write
- 트랜잭션을 시작할 때 Shared/Exclusive Lock을 적용한다. 따라서 동시성 충돌이 잦을 것으로 예상되어 동시성을 강력하게 지켜야 할 때 사용하여 야 한다.
- 충돌이 빈번하게 일어난다면 Optimistic보다 성능이 좋고, 데이터 정합성이 안정적이다. 하지만 별도의 Lock을 잡기 때문에 속도가 느리고, 경우에 따라 DeadLock 의 위험성이 있음은 유의 해야 한다.
- 단일 테이블에 요청을 하는 경우 가능성이 적지만 여러 테이블에 Lock을 걸면서 서로 자원이 필요한 경우 데드락이 발생할 수 있으며, 비관적 락으로 해결할 수 없다. 다음과 같은 예시 상황이 있다
- 트랜잭션 A가 테이블1의 1번 데이터에 lock을 획득
- 트랜잭션 B가 테이블2의 1번 데이터에 lock을 획득
- 트랜잭션 A가 테이블2의 1번 데이터에 lock 획득 시도(실패 - 대기)
- 트랜잭션 B가 테이블1의 1번 데이터에 lock 획득 시도(실패 - 대기)
2)DeadLock(교착 상태)
- 둘 이상의 프로세스(트랜잭션)들이 자원을 점유(Lock을 획득)한 상태에서 서로 다른 프로세스가 점유하고 있는 자원(Lock)을 요구하며 무한정 기다리는 상황을 의미한다.
3)Redisson 분산락
- Redisson은 락 충돌을 처리하기 위해 분산 락 메커니즘을 사용한다. 여러 서버에서 락을 건다면 최대 락을 걸 수 있는 시간, 다른 서버에서 기다리는 최대 시간을 설정하여 DeadLock 상태를 방지한다.
3. 참조
1)여러 Lock의 특성과 testcode : https://sigridjin.medium.com/weekly-java-%EA%B0%84%EB%8B%A8%ED%95%9C-%EC%9E%AC%EA%B3%A0-%EC%8B%9C%EC%8A%A4%ED%85%9C%EC%9C%BC%EB%A1%9C-%ED%95%99%EC%8A%B5%ED%95%98%EB%8A%94-%EB%8F%99%EC%8B%9C%EC%84%B1-%EC%9D%B4%EC%8A%88-9daa85155f66