2012-02-15 23 views
7

que implementa un chat, utilizando ajax sondeo largo y GEvent. Para leer, el cliente ajax la vista de actualización y espera con Gevent.event.wait para una actualización.Django, Ajax sondeo largo, PostgreSQL: transacción inactivo

Problema: La transacción Postgresql abierta por Django al comienzo de una solicitud (para obtener información de la sesión) no se cierra hasta el final de la solicitud. Y esas transacciones inactivas llevan mucha memoria.

¿Cuál puede ser la manera más limpia para cerrar la transacción Postgresql sin cerrar la solicitud? Actualmente estoy enviando la señal request_finished manualmente, pero se siente como un hack.

Respuesta

2

La forma en que lo está haciendo es probablemente el de la mejor manera en el marco de su corte de todos modos. ¿Hay alguna razón por la que intentes calzar el sondeo largo en el proceso de solicitud-respuesta en lugar de usar algo como django-socketio?

+0

Hemos perdido mucho tiempo tratando de hacer el trabajo socketio través de Nginx (front-end) con GEvent/gunicorn/Apache (back-end). Nginx no puede hacer eso sin una gran cantidad de modificaciones. E incluso con aquellos que no fueron capaces de enlazar el identificador de usuario socketio con el identificador de sesión de Django, por lo que no fueron capaces de obtener información de los usuarios. Si tiene un tutorial completo para recomendar, nos encantaría verlo. La mayor parte del tutorial de chatio-chat que encontramos, no usa información de usuario django o una interfaz. – Ashe

+1

en cuanto a hacer SocketIO y Django backends de autenticación trabajan juntos: https://gist.github.com/fd8e9631368e447de702 –

+0

Para ser honesto, no vamos a deshacer en este momento, pero definitivamente vamos a tener eso para más adelante. Gracias. – Ashe

0

Ver aquí: 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 si lo prefiere gestores de contexto:

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

Además, si usted está teniendo problemas de memoria que llevan a cabo las conexiones PostgreSQL abra usted debe buscar una solución mediante la puesta en común o pgbouncer las diversas piscinas de conexión gevent que existen. Debería ver algunos aumentos de rendimiento considerables al hacer esto.

+0

Hemos intentado con la reversión, haremos una prueba con commit y validaremos la respuesta si funciona. Y eche un vistazo a los technos que recomienda. ¡Gracias por la respuesta! – Ashe

+0

No funciona para nosotros. Supongo que la transacción se abrió dentro del commit_manually y la abierta previamente por django no es la misma (o hay algo que no entendemos). Todavía tenemos la conexión inactiva cuando usamos esta técnica en lugar de la nuestra (fea) hack. – Ashe

Cuestiones relacionadas