동시성문제란?
여러 프로세스가 같은 데이터에 접근하여 생기는 경쟁 상황(race condition)
경쟁상황(race condition)이란?
동시에 여러개의 프로세스가 하나의 공유자원(데이터)에 대해 접근하여 연산을 진행하면서 발생하는 경쟁 상황
임계구역(critical section)이란?
코드상에서 경쟁조건이 발생할 수 있는 특정 부분
임계구역에서 발생할 수 있는 문제를 해결하는 방법
- 상호배제
- 이미 한 프로세스가 critical section에서 작업중일때 다른 프로세스는 이곳에 진입해서는 안된다
- 진행(Progress)
- 아무도 critical section에 작업중이지 않다면 다른 프로세스는 들어올수있어야한다
- 한정대기(Bounded waiting)
- critical section에 진입하려는 프로세스가 무한하게 대기해서는 안된다
Lock
데이터의 동시 수정을 방지하는 전략입니다
비관적 락
- 충돌이 발생할 수 있으므로 데이터를 수정하기 전에 미리 락을 걸어야 한다는 "비관적" 가정 하에 미리 lock을 사용합니다
- 작동 방식: 데이터를 읽을 때부터 데이터에 락을 걸어 다른 트랜잭션이 해당 데이터를 수정하거나 락을 걸지 못하게 합니다.
- 데이터베이스 지원: 실제 데이터베이스에서 제공하는 락 메커니즘을 사용합니다.
- 유형: 비관적 락에는 주로 PESSIMISTIC_READ (다른 트랜잭션의 쓰기를 막음) 및 PESSIMISTIC_WRITE (다른 트랜잭션의 읽기 및 쓰기를 모두 막음)의 두 가지 유형이 있습니다.
- 장점: 충돌의 위험이 없으며 예측 가능한 동작을 합니다.
- 단점: 락으로 인해 대기 시간이 길어질 수 있으며, *데드락(Deadlock)의 위험이 있습니다.
- *데드락: 두 프로세스가 서로 종료될때까지 대기하는 프로그램
낙관적 락
- 대부분의 트랜잭션 충돌이 발생하지 않을 것이라는 "낙관적"인 가정 하에 충돌 발생 시 이를 감지하고 처리하는 방식입니다.
- 작동 방식: 데이터를 읽을 때 락을 걸지 않습니다. 대신, 데이터를 업데이트할 때 해당 데이터가 마지막으로 읽힌 이후에 변경되지 않았는지 확인합니다.
- 버전 관리: 대부분의 구현에서는 @Version과 같은 어노테이션을 사용하여 엔티티에 버전 번호를 부여합니다. 데이터가 수정될 때마다 이 버전 번호가 증가합니다.
- 충돌 감지: 만약 두 트랜잭션이 거의 동시에 같은 데이터를 수정하려고 시도하면, 버전 번호가 불일치하게 되어 충돌이 감지됩니다. 이 경우, 예외가 발생합니다 (예: OptimisticLockException).
- 시작 상황: 데이터베이스에 있는 Product 엔터티에는 price라는 필드와 version이라는 필드가 있다고 가정하겠습니다. Product의 price는 100이고, version은 1입니다.
- 동시 트랜잭션 시작: 두 사용자 A와 B가 거의 동시에 Product 엔터티를 읽어옵니다. 둘 다 price는 100, version은 1로 읽힙니다.
- A의 수정: 사용자 A는 price를 110으로 수정하고 이를 저장하려고 합니다. 이때, 시스템은 version 필드를 체크하고, 변경 전과 같은 1을 발견합니다. 따라서 A의 요청이 유효하다고 판단하고 price를 110으로 수정합니다. 그리고 version을 1 증가시켜 2로 만듭니다.
- B의 수정: 이제 사용자 B가 price를 120으로 수정하고 저장하려고 합니다. 하지만 B가 데이터를 읽었을 때의 version은 1이었습니다. 시스템은 현재 Product의 version이 2인 것을 확인하고, B가 가지고 있는 데이터의 version과 일치하지 않다는 것을 알게 됩니다.
- 충돌 감지: 시스템은 이러한 버전 불일치를 "충돌"로 감지하며, 이 경우 사용자 B의 변경을 허용하지 않고 OptimisticLockException과 같은 예외를 발생시킵니다.
- 장점: 데이터베이스 자원을 적게 사용하며, 락으로 인한 대기 시간이 적습니다.
- 단점: 동시 업데이트 시 충돌 발생 가능성이 있습니다.