2012-02-15 14 views
7

Ho implementato una chat, utilizzando un sondaggio ajax lungo e Gevent. Per leggere, il client aggiorna la vista di aggiornamento e attendi con Gevent.event.wait per un aggiornamento.Django, Ajax polling lungo, Postgresql: transazione inattiva

Problema: La transazione Postgresql aperta da Django all'inizio di una richiesta (per ottenere informazioni sulla sessione) non viene chiusa fino alla fine della richiesta. E quelle transazioni inattive prendono molta memoria.

Quale sarebbe il modo più pulito per chiudere la transazione Postgresql senza chiudere la richiesta? Attualmente sto inviando manualmente il segnale request_finished ma sembra un trucco.

risposta

2

Il modo in cui lo stai facendo è probabilmente il modo migliore all'interno della struttura del tuo hack in ogni caso. C'è qualche ragione per cui stai provando a scrivere a lungo sul processo di richiesta-risposta invece di usare qualcosa come django-socketio?

+0

Abbiamo perso molto tempo cercando di fare funzionare socketio tramite nginx (front-end) con gevent/gunicorn/apache (back-end). Nginx non è in grado di farlo senza un'alta quantità di mod. E anche con quelli, non siamo stati in grado di collegare l'ID utente socketio con l'id della sessione django, quindi non siamo stati in grado di ottenere le informazioni dell'utente. Se hai un tutorial completo da consigliare, ci piacerebbe vederlo. La maggior parte del tutorial di socketio - chat che abbiamo trovato, non usa le informazioni utente di django o un front end. – Ashe

+1

Per quanto riguarda il funzionamento dei backend di SocketIO e django: https://gist.github.com/fd8e9631368e447de702 –

+0

Per essere onesti, non eseguiremo il rollback adesso, ma lo terremo definitivamente per dopo. Grazie. – Ashe

0

vedere qui: https://docs.djangoproject.com/en/dev/topics/db/transactions/#django.db.transaction.commit_manually

@transaction.commit_manually 
def yourview(request): 
    # do your db actions 
    transaction.commit() 

O se preferite manager contesto:

def yourview(request): 
    ... 
    with transaction.commit_manually(): 
     # do your db actions 
    ... 

anche se si hanno problemi di memoria in possesso di collegamenti di PostgreSQL aprire si dovrebbe cercare una soluzione di pooling utilizzando pgbouncer o i vari pool di connessione gevent esistenti. Dovresti vedere alcuni notevoli guadagni in termini di prestazioni da questo.

+0

Abbiamo provato con il rollback, effettueremo un test con commit e convalideremo la risposta se funziona. E dai un'occhiata alle tecnologie che hai consigliato. Grazie per la risposta! – Ashe

+0

Non funziona per noi. Immagino che la transazione sia stata aperta all'interno di commit_manually e quella aperta in precedenza da django non sia la stessa (o c'è qualcosa che non capiamo). Abbiamo ancora la connessione inattiva quando usiamo questa tecnica al posto del nostro (brutto) trucco. – Ashe

Problemi correlati