Co powinienem zrobić, gdy optymistyczne blokowanie nie działa?

Mam następujący scenariusz:

1. Użytkownik wysyła żądanie GET/projects/1 i otrzymuje znacznik ETag .
2. Użytkownik wysyła żądanie PUT do /projects/1ETag z kroku # 1.
3. Użytkownik /projects/1przesyła kolejne żądanie PUT do ETag z kroku # 1.

Zwykle drugie żądanie PUT otrzymałoby odpowiedź 412, ponieważ ETag jest teraz nieaktualny - pierwsze żądanie PUT zmodyfikowało zasób, więc ETag już się nie zgadza.

Ale co, jeśli dwa żądania PUT zostaną wysłane w tym samym czasie (lub dokładnie jedno po drugim)? Pierwsze żądanie PUT nie ma czasu na przetworzenie i aktualizację zasobu przed przybyciem PUT nr 2, co powoduje zastąpienie PUT nr 1 przez PUT nr 2. Cały sens optymistycznego blokowania polega na tym, aby tak się nie stało ...

Mechanizm ETag określa tylko protokół komunikacyjny dla optymistycznego blokowania. Usługa aplikacji jest odpowiedzialna za wdrożenie mechanizmu wykrywania równoczesnych aktualizacji w celu wymuszenia optymistycznej blokady.

W typowej aplikacji korzystającej z bazy danych zwykle robisz to, otwierając transakcję podczas przetwarzania żądania PUT. Zwykle odczytujesz istniejący stan bazy danych w tej transakcji (aby uzyskać blokadę odczytu), sprawdzasz ważność Etag i zastępujesz dane (w sposób, który spowoduje konflikt zapisu, gdy dojdzie do jakiejkolwiek niezgodnej transakcji równoległej), następnie popełnij. Jeśli poprawnie skonfigurujesz transakcję, jeden z zatwierdzeń powinien zakończyć się niepowodzeniem, ponieważ oba będą próbowały jednocześnie aktualizować te same dane. Będziesz wtedy mógł użyć tej niepowodzenia transakcji, aby zwrócić 412 lub ponowić żądanie, jeśli ma to sens dla aplikacji.

Musisz wykonać atomowo następującą parę:

• sprawdzanie poprawności znacznika (tj. jest aktualne)
• aktualizowanie zasobu (w tym aktualizowanie jego znacznika)

Inni nazywają to transakcją - ale zasadniczo atomowe wykonanie tych dwóch operacji uniemożliwia zastąpienie drugiej przypadkowym przypadkiem; bez tego masz wyścig, jak zauważasz.

Jest to nadal uważane za optymistyczne blokowanie, jeśli spojrzysz na duży obraz: że sam zasób nie jest blokowany przez początkowy odczyt (GET) przez dowolnego użytkownika lub użytkowników, którzy patrzą na dane, czy to z zamiarem aktualizacji, czy nie.

Niektóre zachowania atomowe są konieczne, ale dzieje się to w ramach pojedynczego żądania (PUT), a nie próby zablokowania wielu interakcji sieciowych; jest to optymistyczne blokowanie: obiekt nie jest blokowany przez GET, ale nadal można go bezpiecznie zaktualizować za pomocą PUT.

Istnieje również wiele sposobów na atomowe wykonanie tych dwóch operacji - zablokowanie zasobu nie jest jedyną opcją; na przykład może wystarczyć lekka blokada wątku lub obiektu i zależy ona od architektury aplikacji i kontekstu wykonania.

Twórca aplikacji musi sprawdzić E-Tag i podać tę logikę. Nie jest magią, że serwer WWW robi to za Ciebie, ponieważ wie tylko, jak obliczyć E-Tagnagłówki dla zawartości statycznej. Weźmy więc powyższy scenariusz i opiszmy, jak powinna wyglądać interakcja.

GET /projects/1

Serwer otrzymuje żądanie, określa E-Tag dla tej wersji rekordu, zwracając go wraz z faktyczną zawartością.

200 - OK
E-Tag: "412"
Content-Type: application/json
{modified: false}

Ponieważ klient ma teraz wartość E-Tag, może to uwzględnić w PUTżądaniu:

PUT /projects/1
If-Match: "412"
Content-Type: application/json
{modified: true}

W tym momencie aplikacja musi wykonać następujące czynności:

• Sprawdź, czy E-Tag jest nadal poprawny: „412” == „412”?
• Jeśli tak, dokonaj aktualizacji i oblicz nowy E-Tag

Wyślij odpowiedź powodzenia.

204 No Content
E-Tag: "543"

Jeśli nadejdzie inne żądanie i spróbuje wykonać PUTpodobne do powyższego, za drugim razem, gdy kod serwera je oceni, będziesz odpowiedzialny za przesłanie komunikatu o błędzie.

• Sprawdź, czy znacznik E jest nadal poprawny: „412”! = „543”

W przypadku awarii wyślij odpowiedź awarii.

412 Precondition Failed

To jest kod, który musisz napisać. E-Tag może w rzeczywistości być dowolnym tekstem (w granicach określonych w specyfikacji HTTP). To nie musi być liczba. Może to być również wartość skrótu.

Jako uzupełnienie innych odpowiedzi opublikuję jeden z najlepszych cytatów w dokumentacji ZeroMQ, który wiernie opisuje podstawowy problem:

Aby stworzyć całkowicie doskonałe programy MT (i mam na myśli to dosłownie), nie potrzebujemy muteksów, blokad ani żadnej innej formy komunikacji między wątkami, z wyjątkiem wiadomości wysyłanych przez gniazda ZeroMQ.

Przez „doskonałe programy MT” rozumiem kod, który jest łatwy do napisania i zrozumienia, który działa z tym samym podejściem projektowym w dowolnym języku programowania i na dowolnym systemie operacyjnym, i który skaluje się na dowolnej liczbie procesorów z zerowymi stanami oczekiwania i bez sensu malejących zysków.

Jeśli spędziłeś lata na nauce sztuczek, aby Twój kod MT w ogóle działał, a tym bardziej szybko, dzięki blokadom, semaforom i sekcjom krytycznym, będziesz zniesmaczony, gdy zdasz sobie sprawę, że to wszystko na nic. Jeśli jest jedna lekcja, którą wyciągnęliśmy z ponad 30 lat równoczesnego programowania, to: po prostu nie udostępniaj stanu. To jak dwóch pijaków próbujących wypić piwo. Nie ma znaczenia, czy są dobrymi kumplami. Wcześniej czy później zamierzają walczyć. Im więcej pijaków dodasz do stołu, tym bardziej walczą ze sobą o piwo. Tragiczna większość aplikacji na MT wygląda jak bójka po pijanemu.