사용자가 편집하는 동안 내 클라우드 DB에서 행을 잠 가야합니까?

클라우드에 데이터를 유지하는 데스크톱 응용 프로그램을 만들고 있습니다. 내가 가진 한 가지 우려는 응용 프로그램에서 항목을 편집하고 잠시 동안 데이터를 오래 쓸 수 없게 만드는 시작입니다. 두 사람이 동시에 같은 항목을 편집하려고 할 때도 이런 일이 발생할 수 있습니다. 편집을 마치고 데이터를 저장하려는 경우 현재 데이터베이스에있는 내용을 덮어 쓰거나 마지막 변경 후 편집을 시작했는지 확인하고 변경 사항을 취소하거나 위험에 대한 옵션을 제공해야합니다. 다른 사람의 변경 사항을 덮어 씁니다.

필드 is_locked와 lock_timestampDB 테이블을 추가하는 것에 대해 생각했습니다 . 사용자가 항목을 편집하기 시작하면 행이 is_lockedtrue로 변경 되고 잠금 시간 소인이 현재 시간으로 설정됩니다. 그런 다음 잠금이 유지되는 시간이 약간 있습니다 (예 : 5 분). 다른 사람이 항목을 편집하려고하면 항목이 잠겨 있고 잠금이 자동으로 만료된다는 메시지가 나타납니다. 잠금을 편집하는 동안 사용자가 걸어 나가면 잠금이 비교적 짧은 시간 후에 자동으로 만료되고 잠금이 만료되면 사용자에게 잠금이 만료되었다는 경고가 표시되고 데이터를 새로 고친 후 편집을 다시 시작해야합니다.

오래된 데이터 덮어 쓰기를 방지하는 좋은 방법입니까? 과잉입니까 (단일 계정에서 여러 사람이 동시에 응용 프로그램을 사용할 것으로 기대하지는 않습니다).

(내가 가진 또 다른 관심사는 2 명의 사람들이 같은 물건에 대해 자물쇠를 얻는 것입니다. 그러나 그것이 내가 편안하게 경쟁 조건이라고 생각합니다.)

여기서 도움이 될 한 가지는 용어입니다. 여기서 설명하는 것을 '비관적 잠금'이라고합니다. 이 방법의 주요 대안은 '낙관적 잠금'입니다. 비관적 잠금에서는 각 행위자가 레코드를 업데이트하기 전에 레코드를 잠그고 업데이트가 완료되면 잠금을 해제해야합니다. 낙관적 잠금에서는 다른 사람이 레코드를 업데이트하고 있다고 가정하지 않습니다. 다른 액터가 레코드를 변경 한 경우 업데이트에 실패합니다.

두 명의 액터가 동시에 같은 것을 업데이트 할 가능성이 낮 으면 일반적으로 낙관적 잠금이 바람직합니다. 비관론은 일반적으로 그 가능성이 높거나 시작하기 전에 업데이트가 성공할 수 있는지 알아야 할 때 사용됩니다. 내 경험상, 비관적 잠금에는 많은 문제가 있기 때문에 낙관적 잠금이 거의 항상 선호됩니다. 가장 큰 문제 중 하나가 귀하의 질문에 있습니다. 사용자는 편집을 위해 레코드를 잠근 다음 점심 식사를 위해 떠날 수 있습니다. 완화가 도움이 될 수 있지만 사용자 경험은 낙관적 접근 방식보다 나쁘지 않으며 훨씬 나빠질 수 있습니다. 예를 들어, 한 명의 사용자가 레코드를 열고 업데이트를 시작하면 상사가 책상에 나타납니다. 다른 사용자가 레코드를 편집하려고합니다. 잠겨 있습니다. 두 번째 사용자는 계속 시도하고 5 분 후에 잠금이 만료되고 두 번째 사용자가 레코드를 업데이트합니다. 첫 번째 사용자는 화면으로 돌아가서 저장을 시도하고 잠금을 잃었다는 메시지를받습니다. 이제 낙관적 잠금을 사용하는 것을 제외하고는 모두 동일한 시나리오에서 첫 번째 사용자의 경험은 거의 동일하지만 두 번째 사용자는 5 분을 기다리지 않습니다.

잠금 값에 대해 낙관적 잠금을 구현하면 배치 방식이 크게 향상되지만 내 생각에 낙관적 잠금은 아마도 모든 것이 정상이며 is_locked 필드를 제거 할 수 있습니다.

사용중인 '클라우드 DB'를 제공하지 않습니다. 자체 솔루션을 구현하기 전에 해당 기능을 조사하여 내장 기능이 있는지 확인할 수 있습니다.

기본 레시피는 다음과 같습니다. is_locked 필드 대신 버전 번호 필드가 있습니다. 레코드를 검색 할 때 현재 버전의 레코드를 가져옵니다. 업데이트 할 때 검색 한 내용과 일치하는 버전 필드에서 업데이트를 조건에 맞게 만들고 성공하면 업데이트합니다. 버전이 일치하지 않으면 업데이트가 적용되지 않고 실패로 다시보고합니다.

에서 JimmyJames의 대답 @ , 우리는 질문에 대해 정말 얼마나 볼 수있는 사용자 경험 .

그것은 모두 상황에 달려 있습니다. 레코드를 업데이트하는 데 시간과 노력이 얼마나 걸립니까? 여러 사용자가 동일한 문서를 얼마나 자주 업데이트하려고합니까?

예를 들어, 사용자가 일반적으로 레코드를 업데이트하는 데 몇 초가 걸리고 경합이 거의 없다면 낙관적 잠금이 바람직 할 것입니다. 최악의 경우 사용자는 문서를 업데이트하는 데 몇 초 (최대 1 분)를 더 소비해야합니다.

문서의 내용이 많지만 구조가 잘 짜여 있으면 문서를 개별 필드를 30 초 단위로 잠그는 방식으로 잠금을 확장 할 수 있도록 타이머 또는 눈에 띄지 않는 알림을 표시 할 수 있습니다.

그러나 사용자가 상당한 시간이나 노력을 소비하는 경우 다른 방법을 고려해야합니다. 기록이 잘 정리되어 있습니까? 서버의 버전과 저장하려는 버전 간의 비교 (diff)를 사용자에게 보여줄 수 있습니까? 차이점을 강조 할 수 있습니까? 변경 사항을 병합 할 수 있습니까 ? 소스 제어 도구에 대한 경험을 생각해보십시오. 당신은 정말로 그 모든 코드를 다시 작성하도록 강요하고 싶지 않습니다!

추가 영감을 얻으려면 Google 문서를 살펴보십시오. 새 버전이 저장되었다는 알림을 사용자에게 표시 할 수 있습니다. 어쩌면 덜 논쟁적인 시간에 돌아올 수 있도록 얼마나 많은 사람들이 레코드를 열 었는지 보여줄 수 있습니다.