Powód WATCH nie jest ujawniany bezpośrednio ze względu na sposób, w jaki SE.Redis jest zaprojektowany do multipleksowania poleceń z różnych stosów wywołań w jednym połączeniu. To sprawia, że każda transakcja musi być bardzo ściśle zarządzany.
Nie jestem do końca jasne, jaki byłby cel „niezmienionego” samego w sobie , bez porównania z jakąś znaną wartością - w przeciwnym razie tworzysz tylko warunek wyścigu. Na pewno byłoby możliwe dodanie obsługi, ale naprawdę chciałbym najpierw zrozumieć oczekiwany przypadek użycia. Czy możesz wyjaśnić?
Ponownie swoją edycję; Twój preferowany przykład (ostatni) po prostu nie jest możliwy z redis - nic wspólnego z SE.Redis; jeśli wykonasz GET wewnątrz MULTI , nie otrzymasz odpowiedzi, dopóki EXEC kończy się - więc nie możesz użyć wartości w SET :nie jest jeszcze dostępne .
Gdyby nie multipleksowanie, możesz nieco zmienić kolejność drugiego przykładu (na podstawie tego, co robi SE.Redis):
WATCH key
val = GET key
MULTI
val = val + 1
SET key $val
EXEC
to jest typowy użycie WATCH :ty oglądasz rzeczy, o które pytasz z wyprzedzeniem, wiesz, że {key} nie zmienia się podczas tej pętli (lub przynajmniej transakcja zostanie przerwana; brak niespójnego stanu). Jednak WATCH nie działa dobrze z multiplekserem , dlatego SE.Redis zmusza Cię do podążania drogą pobierania wartości przed transakcją , a następnie umożliwiając porównanie wartości w celu stwierdzenia, że jest niezmieniona. Ten sam wynik; nieco inne podejście, ale jest bezpieczne dla multipleksera. Więcej informacji na ten temat znajdziesz tutaj.
