낙관적 락이 LOST UPDATE 문제를 방지할 수 있나요?

Question

안녕하세요.. 낙관적 락과 LOST UPDATE 관련된 질문이 있습니다.제가 뭔가 놓치고 있는 기본적인 게 있는 것 같은데, 어떤 걸 놓치고 있는지 모르겠어서 질문드립니다Tx A) UPDATE some_tableSET x = x + 10WHERE id = 1;Tx B) UPDATE some_tableSET x = x + 20WHERE id = 1;위의 두 쿼리는 동시 실행 시 다음 과정에 의해 LOST UPDATE 문제가 발생 가능합니다.1. Tx A, Tx B가 동시에 id = 1인 레코드를 조회(x = 10)2. Tx A가 본인이 읽은 x를 20으로 증가시키며 커밋3. Tx B가 본인이 읽은 x를 30으로 증가시키며 커밋4. Tx A가 갱신한 것이 덮어씌워진 셈 → LOST UPDATE 발생그러면 같은 논리로, 테이블에 version 컬럼을 추가해 낙관적 락을 사용하는 경우도 LOST UPDATE가 생기지 않나요?Tx A) UPDATE some_table SET x = x + 10, version = version + 1 WHERE version = 1 AND id = 1;Tx B) UPDATE some_table SET x = x + 20, version = version + 1 WHERE version = 1 AND id = 1;1. Tx A, Tx B가 동시에 id = 1, version = 1인 레코드를 조회 (x = 10, version = 1)2. Tx A가 본인이 읽은 x를 20으로 증가시키고 본인이 읽은 version을 2로 증가시키며 커밋3. Tx B가 본인이 읽은 x를 30으로 증가시키고 본인이 읽은 version을 2로 증가시키며 커밋4. Tx A가 갱신한 것이 덮어씌워진 셈 → LOST UPDATE 발생

Devvy · Answer

그러면 같은 논리로, 테이블에 version 컬럼을 추가해 낙관적 락을 사용하는 경우도 LOST UPDATE가 생기지 않나요? Tx A) UPDATE some_table SET x = x + 10, version = version + 1 WHERE version = 1 AND id = 1; Tx B) UPDATE some_table SET x = x + 20, version = version + 1 WHERE version = 1 AND id = 1; 1. Tx A, Tx B가 동시에 id = 1, version = 1인 레코드를 조회 (x = 10, version = 1) 2. Tx A가 본인이 읽은 x를 20으로 증가시키고 본인이 읽은 version을 2로 증가시키며 커밋 3. Tx B가 본인이 읽은 x를 30으로 증가시키고 본인이 읽은 version을 2로 증가시키며 커밋 4. Tx A가 갱신한 것이 덮어씌워진 셈 → LOST UPDATE 발생Isolation level과 내부 구현에 따라 그 결과가 달라질 것 같습니다 .만약 Tx A가 업데이트한 결과를 Tx B에서 볼 수 있다면(SET x = x + 10, version = version + 1) version이 이미 증가된 상태이기 때문에 Tx B의 업데이트 작업은 WHERE 조건절이 충족되지 않아서 Tx A의 업데이트만 반영됩니다(MySQL 동작방식)

캐티 · Answer

현실적으로 락을 사용하빈다. 이렇다 하더라도 블록 캐싱을 사용하면 두 컨텍스트를 동시에 처리하더라도 데이터를 공유하여서 이런 문제가 안 생기는데요. 이렇다 하더라도 cpu 안에서도 컨텍스트 복제가 일어나고, L3 공유 캐시는 하나이지만 L2 L1은 같은 데이터를 복제하여서 처리하고 가져오는데 이 과정에서 위의 데이터 손실이 발생하여요. 이러면 경합되지 않는 알고리즘을 사용해야 하빈다.컴퓨터의 작동 원리를 알고 있다면, 위의 공통 데이터를 사용하지 않고, 분할하거나 일정한 데이터를 누적 한 다음 일괄적으로 처리하겠쩌. 비트 코인이 10분마다 블록을 새로 생성하는 방식을 취하고 있어요. 이케하면 적절하게 경합 상태를 피할 수 있겠쩌. 실제 구현은 더 복잡하는것이어요.

Devvy · Answer

Tx A) UPDATE some_table SET x = x + 10 WHERE id = 1; Tx B) UPDATE some_table SET x = x + 20 WHERE id = 1; 위의 두 쿼리는 동시 실행 시 다음 과정에 의해 LOST UPDATE 문제가 발생 가능합니다.말씀주신 내용과 관련해서 재밌는 사실 .... MySQL은 lost update가 발생하지만 PostgreSQL은 발생하지 않습니다(PostgreSQL은 이후에 실행되는 트랜잭션을 팅겨냅니다). 즉 lost update 감지 메카니즘 유무, 그리고 DBMS 내부 구현에 따라 lost update가 발생하거나 발생하지 않을 수 있습니다.

정말잘하고싶은사람 · Answer

@Devvy안녕하세요, 답변 감사드립니다.음 말씀해주신 건 트랜잭션 A에서 update 쿼리가 실행된 후 트랜잭션 B에서 update쿼리가 실행되는 상황으로 이해했는데요.제가 쿼리의 정확한 실행방식을 아는 것은 아니나, UPDATE쿼리도 결국 데이터를 read하고 write하는 두 작업으로 쪼갤 수 있는 걸로 알고 있어서, 다음과 같은 상황이 벌어지면 LOST UPDATE가 발생할 수 있다는 생각이 들었습니다.Tx A, Tx B 가 실행되면서 Lost update가 없었다면 기대값은 40일테지만(version = 3),위 그림처럼 되면 되면 결국 Tx A가 x += 10했던 게 씹히는 결과가 나올 것 같았습니다!혹시 제가 잘못 알고 있는 게 있을까요..?

집킨 · Answer

낙관적 락은 애플리케이션 레벨에서 구현해야합니다즉, 어떻게 구현하느냐에 따라서 LOST UPDATE 가 발생할 수 도 있고 아닐수도 있는거죠(DBMS의 isolation level 에도 영향을 받는데 여기선 그냥 제외하겠습니다)본문의 코드대로 하면 LOST UPDATE 가 발생할 수 있습니다txA가 커밋하기 전에 txB가 실행되고 커밋되는 상황이겠죠하지만 트랜잭션이 커밋하기 전에 version 을 조건으로 select 해서 버전 체크를 하게 하면 LOST UPDATE 는 피할 수 있습니다txA든 txB든 한쪽은 실패할 수 밖에 없으니까요

낙관적 락이 LOST UPDATE 문제를 방지할 수 있나요?

5개의 답변

#lock 목록