Jeśli mam rację, wygląda na to, że mówisz o formie przeprawy typu check-out/edit/check-in. Jeśli jeden użytkownik edytuje rekord, żaden inny użytkownik nie może rozpocząć edycji tego samego rekordu.
To jest forma pesymistycznej współbieżności. Wiele frameworków dostępu do sieci i danych obsługuje (podobną) współbieżność optymalizującą - to znaczy, że powiedzą ci, że ktoś inny już zmienił rekord, gdy próbowałeś zapisać. Optymistycznie nie ma pojęcia o blokowaniu - zapewnia, że żaden inny użytkownik nie będzie zapisywał między czasem pobrania a czasem zapisania.
To, czego oczekujesz, nie jest łatwym wymogiem w Internecie, ponieważ serwer naprawdę nie ma możliwości wymuszenia zameldowania, gdy użytkownik przerwie edycję (na przykład zamykając przeglądarkę). Nie znam żadnych frameworków, które radzą sobie z tym w ogóle.
Zasadniczo potrzebne jest posiadanie informacji o kasie na serwerze. Proces użytkownika podczas edycji wymagałby zamówienia, a serwer udzieliłby/odmówiłby tego na podstawie tego, co sprawdzał. Serwer musiałby również przechowywać informacje o tym, że zasób jest wyrejestrowany. Kiedy użytkownik zapisuje serwer, zwalnia blokadę i pozwala na nowe zamówienie na żądanie. Problem pojawia się, gdy użytkownik przerwie edycję - jeśli jest to przez interfejs użytkownika, nie ma problemu ... po prostu powiedz serwerowi, aby zwolnił blokadę.
Ale jeśli to przez zamknięcie przeglądarki, wyłączenie maszyny, itp. Masz osieroconą blokadę. Większość ludzi rozwiązuje ten jeden z dwóch sposobów: 1. Limit czasu. Blokada zostanie ostatecznie zwolniona. Plusem jest to, że jest dość łatwy i niezawodny. Wadą jest to, że rekord jest zablokowany na jakiś czas, gdzie nie jest on w rzeczywistości edytowany. Musi też upłynąć wystarczająco dużo czasu, aby zaoszczędzić użytkownikowi, który naprawdę długo nie zapisał błędu, ponieważ czas blokady minął (i muszą zacząć od nowa). 2. Bicie serca. Użytkownik regularnie wysyła polecenie ping do serwera, aby powiedzieć "tak, nadal edytuj". Jest to w zasadzie opcja limitu czasu z # 1, ale z naprawdę krótkim czasem oczekiwania, który można odświeżać na żądanie. Plusem jest to, że możesz zrobić dowolnie krótko. Minusem jest zwiększona złożoność i wykorzystanie sieci.
Tokeny checkin/checkout naprawdę nie są trudne do wdrożenia, jeśli masz już przetransaktywowany, trwały sklep (jak DB): trudnym elementem jest zintegrowanie go z wygodą użytkownika.
Nie jestem pewien, czy podążam. Szukasz pesymistycznego systemu zamków, który uniemożliwia użytkownikowi edycję czegoś, co według niego jest już w trakcie edycji? ALBO czy szukasz czegoś optymistycznego, co pozwala na wielokrotną edycję, ale odrzuca zgłoszenia po zmianie danych? – AnthonyWJones
Pesymistyczny scenariusz blokowania jest zbyt ograniczony, więc podrapuję ten pomysł.Nie chcę, aby użytkownicy edytowali przez 30 minut, aby odrzucić zmiany, gdy ktoś inny pobije ich do przesłania zmiany. –
Jednak optymistyczny scenariusz łączenia wymaga wiele dodatkowej pracy z mojej strony, ponieważ potrzebuję narzędzia, które umożliwiłoby klientowi scalenie właściwości publicznych obiektów, prawdopodobnie w sposób podobny do siatki. –