비관적 락(Pessimistic Lock)

비관적 락은 Repeatable Read 또는 Serializable 정도의 격리 수준을 제공합니다. 높은 수준의 격리 수준인 만큼 트랜잭션이 충돌이 발생할 가능성이 높고 데이터의 정합성이 중요한 케이스에 사용됩니다. 비관적 락은 트랜잭션이 시작 될 때 Shared Lock(공유 락) 또는 Exclusive Lock(배타 락)을 걸고 시작하는 방법입니다.

• Shared Lock을 걸게 되면 다른 트랜잭션에서는 읽기 작업만 가능합니다.
• Exclusive Lock을 걸게 되면 다른 트랜잭션에서는 읽기, 쓰기 작업 모두 불가능합니다.

예시로는 다음과 같은 상황이 있을 수 있습니다.

• 트랜잭션 A가 고객 A의 계좌 잔액을 조회하고 수정하려고 합니다. 이때 비관적 락을 사용하여 잔액에 대한 락을 걸고, 다른 트랜잭션의 접근을 차단합니다.
• 트랜잭션 B가 같은 계좌의 잔액을 조회하려고 하지만, 비관적 락 때문에 대기 상태가 됩니다.
• 트랜잭션 A가 계좌 잔액을 수정하고 커밋한 후, 락이 해제되면 트랜잭션 B가 잔액을 조회할 수 있습니다.

비관적 락은 데이터에 대한 접근이 엄격하므로 보통 데이터의 일관성이 중요하고, 데이터 충돌이 많을 수 있는 상황에서 사용됩니다. 하지만 비관적 락은 높은 수준의 격리 수준을 제공하는 만큼 성능이 저하 될 수 있고 데드락(DeadLock)의 위험성이 존재한다는 단점이 있습니다.

낙관적 락(Optimistic Lock)

낙관적 락(Optimistic Lock)은 대부분의 트랜잭션이 충돌이 발생하지 않을 거라고 낙관적으로 가정하는 방법입니다. 그렇기 때문에 여러 트랜잭션이 동시에 데이터에 접근할 수 있도록 허용해 줍니다. 따라서 DB에서 제공되는 락 기능을 사용하지 않고 엔티티의 버전을 통해 동시성을 제어합니다.

낙관적 락은 DB가 아니라 Application Level에서 처리합니다. 데이터를 내가 먼저 이 값을 수정했다고 명시하여 다른 사람이 동일한 조건으로 값을 수정할 수 없게 하는 것입니다.

예시로는 다음과 같은 상황이 있을 수 있습니다.

• 트랜잭션 A와 트랜잭션 B가 동시에 상품 A의 가격을 수정하려고 합니다. 상품 A의 현재 버전은 1입니다.
• 트랜잭션 A는 상품 가격을 5만원으로 수정하고, 버전을 2로 증가시켜 저장합니다.
• 트랜잭션 B는 상품 가격을 6만원으로 수정하려고 하지만, 저장 시점에 버전 충돌이 발생합니다. 트랜잭션 B는 버전 1이 아닌 2를 발견하므로, 예외를 발생시키거나 변경 작업을 재시도해야 합니다.

낙관적 락은 기본적으로 데이터에 대한 동시 접근을 허용하므로 비관적 락과 비교하여 더 나은 성능을 가진다는 점과 데드락의 위험성이 없다는 장점이 있습니다. 단점은 버전 충돌에 대한 재시도 로직이 필요하고 이러한 버전 충돌이 자주 발생하면 오히려 성능이 저하될 수 있다는 단점이 있습니다.