Django save() zachowanie z transakcjami AUTOCOMMIT

Question

Mam następującą konfigurację:

• Kilka pracownicy przetwarzania danych uzyskać konfigurację z django widzenia get_conf() przez http.
• konfiguracja jest przechowywana w modelu django przy użyciu MySQL/InnoDB backend
• modelu konfiguracja ma przesłonięte save() metodę, która mówi pracownikom, aby przeładować Configuration

Zauważyłem, że czasami pracownicy nie otrzymują poprawnie zmienioną konfigurację. W szczególności, gdy czas przeładowania conf był krótszy niż zwykle, pracownicy otrzymali "starą" konfigurację z get_conf() (brak ostatniej zmiany). Model transakcji używany w Django jest domyślnym autocommit.

I mają pochodzić z poniższego możliwy scenariusz, który mógłby spowodować zachowanie:

1. Nowa konfiguracja zostanie zapisana
2. save() powroty ale MySQL/InnoDB jest nadal przetwarzania (Auto) zobowiązać
3. Pracowników są uruchamiane i tworzą żądanie http dla nowej konfiguracji
4. Zakończenia zatwierdzania MySQL (automatyczne)

Czy krok 2 w powyższym scenariuszu jest możliwy? To znaczy, czy django model save() może powrócić przed faktycznym zatwierdzeniem danych w bazie danych, jeśli używana jest metoda transakcyjna autocommit? Lub, aby przejść o jedną warstwę w dół, czy automatyczne kończenie operacji MySQL INSERT lub UPDATE przed zakończeniem zatwierdzenia (aktualizacja/wstawienie widoczne dla innych transakcji)?

Answer 1

Obiekt może się zabrudzić, spróbuj odświeżyć obiekt po zapisaniu.

obj.save()

obj.refresh_from_db()

referencyjny: https://docs.djangoproject.com/en/1.8/ref/models/instances/#refreshing-objects-from-database

Answer 2

To na pewno wygląda wyścigu.

Scenariusz, który opisujesz, nigdy nie powinien się pojawić, jeśli istnieje tylko jeden skrypt i jedna baza danych. Gdy zapiszesz(), metoda nie powróci, dopóki dane nie zostaną faktycznie zatwierdzone w bazie danych.

Jeśli jednak używasz konfiguracji master/slave, możesz być ofiarą opóźnienia replikacji: jeśli piszesz na wzorcu, ale czytasz na niewolnikach, to jest całkiem możliwe, że twój skrypt nie czeka wystarczająco długo, aby mogła nastąpić replikacja, i czytasz stare conf z niewolnika, zanim miał możliwość powielić mistrza.

Taką konfigurację można skonfigurować w django za pomocą routerów bazodanowych, lub można to zrobić po stronie DB za pomocą proxy DB. Sprawdź to.