Optimistic Lock 경우 이런 케이스일때는 Lost Update 문제 발생 될수 있지 않나요???

Question

이미지가 작게 보인다면 https://cdn.inflearn.com/public/files/posts/2722bc2b-12a3-4512-a5b7-35227283e6ec/aaaa.png 여기로 부탁드립니다!   우선 좋은 강의 배포해주셔서 정말 감사드립니다 :)   우선 설명 하기전에 왼쪽: A 트랜젝션 오른쪽: B 트랜젝션   으로 예시 하겠습니다.   순서를 말씀드리자면   A 트랜젝션 "SELECT * FROM account WHERE id=1;" 구문 실행 B 트랜젝션 "SELECT * FROM account WHERE id=1;" 구문 실행 B 트랜젝션 "UPDATE account SET balance=balance-150, version=2 WHERE id=1 AND version=1;" 업데이트 실행 A트랜젝션 "UPDATE account SET balance=balance-200, version=2 WHERE id=1 AND version=1;" 업데이트 실행 B트랜젝션 Commit 실행 A트랜젝션 Commit 실행 영상에서는 B 트랜젝션을 먼저 Update 문 실행하고 그리고 Commit 을 실행 하고나서   A 트랜젝션을 Update을 하였으니 version 정보가 불일치로 정상적으로 A 트랜젝션은 업데이트가 일어나지 않겠지만   제가 업로드한 이미지 순서대로 하게된다면   즉 A, B 트랜젝션이 동시에 Update를 실행하고 이후 동시에 A, B 트랜젝션이 동시에 Commit 을 실행하면   balance 가 0 으로 되지 않을까요? (A 트랜젝션이 맨 나중에 Commit을 했으니깐) 반대로 B 트랜젝션이 맨 마지막에 Commit을 하게 된다면 balance 값은 50으로 설정되겠지만   정상적으로 업데이트가 된다고 가정시 balance 값은 -150 이 일어나야 하는데요. 이런 케이스 때문에 optimistic Lock 보다 Pessimistic Lock 으로 해야 하지 않을까요????   갑자기 이런 의문이 들어서 질문 드립니다.

이성욱 · Answer

리나님, 안녕하세요. 우선 Real MySQL 시즌 1을 수강해주셔서 감사해요.   우선 질문 주신 내용에서   즉 A, B 트랜젝션이 동시에 Update를 실행하고 이후 동시에 A, B 트랜젝션이 동시에 Commit 을 실행하면   그런데, DBMS 서버에서는, UPDATE할 때마다 먼저 해당 레코드에 대해서 Exclusive Lock을 획득해야만 하기 때문에, 실제 하나의 레코드에 대해서 2개 세션의 UPDATE가 동시에 실행될 수가 없습니다.   그래서 질문주신 내용은 가정이 잘못되어서, 고민하실 상황은 아닌 것으로 보입니다. 혹시 제가 잘못 이해한 부분이 있다면, 다시 한번 질문 부탁드립니다.   감사합니다.