condizioni corsa in django

Question

Ecco un semplice esempio di una vista django con un potenziale condizione di corsa:

# myapp/views.py 
from django.contrib.auth.models import User 
from my_libs import calculate_points 

def add_points(request): 
    user = request.user 
    user.points += calculate_points(user) 
    user.save() 

La condizione di competizione dovrebbe essere abbastanza ovvio: Un utente può fare questa richiesta due volte, e l'applicazione potrebbe potenzialmente eseguire user = request.user contemporaneamente, causando la sovrascrittura di una delle richieste dell'altra.

Supponiamo che la funzione calculate_points sia relativamente complicata e che esegua calcoli basati su tutti i tipi di elementi strani che non possono essere inseriti in un singolo update e che sarebbe difficile inserire una stored procedure.

Quindi, ecco la mia domanda: che tipo di meccanismi di blocco sono disponibili per django, per gestire situazioni simili a questo?

Answer 1

Django 1.4+ supporta select_for_update, nelle versioni precedenti è possibile eseguire query SQL prime per esempio select ... for update che, a seconda del DB sottostante, bloccherà la riga da eventuali aggiornamenti, è possibile fare tutto ciò che si desidera con quella riga fino alla fine della transazione. per esempio.

from django.db import transaction 

@transaction.commit_manually() 
def add_points(request): 
    user = User.objects.select_for_update().get(id=request.user.id) 
    # you can go back at this point if something is not right 
    if user.points > 1000: 
     # too many points 
     return 
    user.points += calculate_points(user) 
    user.save() 
    transaction.commit() 

Answer 2

Hai molti modi per eseguire il single-thread di questo tipo di cose.

Un approccio standard è Aggiornamento prima. Fai un aggiornamento che bloccherà un blocco esclusivo sulla riga; quindi fai il tuo lavoro; e finalmente commetti il ​​cambiamento. Affinché funzioni, è necessario bypassare la memorizzazione nella cache dell'ORM.

Un altro approccio standard consiste nell'avere un server applicazioni separato a thread singolo che isola le transazioni Web dal calcolo complesso.

• L'applicazione web può creare una coda di richieste di punteggio, generare un processo separato, e poi scrivere le richieste di punteggio per questa coda. Lo spawn può essere inserito in Django urls.py in modo che accada all'avvio della web-app. Oppure può essere inserito in uno script di amministrazione separato manage.py. Oppure può essere fatto "secondo necessità" quando viene tentata la prima richiesta di punteggio.

• È inoltre possibile creare un server Web separato con funzionalità WSGI utilizzando Werkzeug che accetta richieste WS tramite urllib2. Se si dispone di un numero di porta singolo per questo server, le richieste vengono accodate da TCP/IP. Se il tuo gestore WSGI ha un thread, allora hai raggiunto il single-threading serializzato. Questo è leggermente più scalabile, poiché il motore di calcolo del punteggio è una richiesta WS e può essere eseguito ovunque.

Un altro approccio è avere un'altra risorsa che deve essere acquisita e tenuta per eseguire il calcolo.

• Un oggetto Singleton nel database. Una singola riga in una tabella univoca può essere aggiornata con un ID di sessione per acquisire il controllo; aggiornare con l'ID di sessione di None per rilasciare il controllo. L'aggiornamento essenziale deve includere un filtro WHERE SESSION_ID IS NONE per garantire che l'aggiornamento non riesca quando il blocco è trattenuto da qualcun altro. Questo è interessante perché è intrinsecamente privo di corsa - si tratta di un singolo aggiornamento - non di una sequenza SELECT-UPDATE.

• Un semaforo da giardino può essere utilizzato all'esterno del database. Le code (generalmente) sono più facili da utilizzare rispetto a un semaforo di basso livello.

Answer 3

Il blocco del database è il modo per andare qui. Ci sono piani per aggiungere il supporto "seleziona per l'aggiornamento" a Django (here), ma per ora il più semplice sarebbe utilizzare SQL raw per AGGIORNARE l'oggetto utente prima di iniziare a calcolare il punteggio.

---

blocco pessimistico è ora supportato da ORM Django 1.4, quando il DB sottostante (come Postgres) supporta. Vedi lo Django 1.4a1 release notes.

Answer 4

Ciò può semplificare eccessivamente la situazione, ma per quanto riguarda la sostituzione di un collegamento JavaScript? In altre parole quando l'utente fa clic sul link o sul pulsante avvolge la richiesta in una funzione JavaScript che disabilita immediatamente/"cancella" il collegamento e sostituisce il testo con le informazioni "Caricamento in corso ..." o "Invio richiesta ..." o qualcosa del genere simile. questo funzionerebbe per te?

Answer 5

A partire da Django 1.1 è possibile utilizzare le espressioni F() dell'ORM per risolvere questo problema specifico.

from django.db.models import F 

user = request.user 
user.points = F('points') + calculate_points(user) 
user.save() 

Per maggiori dettagli si veda la documentazione:

https://docs.djangoproject.com/en/1.8/ref/models/instances/#updating-attributes-based-on-existing-fields

https://docs.djangoproject.com/en/1.8/ref/models/expressions/#django.db.models.F

Answer 6

Ora, è necessario utilizzare:

Model.objects.select_for_update().get(foo=bar)