2011-06-02 14 views
12

¿Son seguros los hilos del middleware de Django? ¿Puedo hacer algo como esto,¿Es seguro el hilo de middleware de Django?

class ThreadsafeTestMiddleware(object): 

    def process_request(self, request): 
     self.thread_safe_variable = some_dynamic_value_from_request 

    def process_response(self, request, response): 
     # will self.thread_safe_variable always equal to some_dynamic_value_from_request? 

Respuesta

27

Por qué no unirse a la variable el objeto de solicitud, así:

class ThreadsafeTestMiddleware(object): 

    def process_request(self, request): 
     request.thread_safe_variable = some_dynamic_value_from_request 

    def process_response(self, request, response): 
     #... do something with request.thread_safe_variable here ... 
+0

Aún mejor podría ser vincularlo a request.session (https://docs.djangoproject.com/en/1.3/topics/http/sessions/). – Bryan

7

No, definitivamente no. Escribo sobre este tema here - el resultado es que almacenar estado en una clase de middleware es una muy mala idea.

Como señala Steve, la solución es agregarlo a la solicitud en su lugar.

+0

Ese enlace está roto. Esta es una correcta: http://blog.roseman.org.uk/2010/02/01/middleware-post-processing-django-gotcha/ –

0

Si está utilizando mod_wsgi en modo daemon con varios subprocesos, ninguna de estas opciones funcionará.

hilos grupo de usuarios = www-data

WSGIDaemonProcess domain.com = www-de datos = 2

Esto es complicado porque va a trabajar con el servidor de django dev (, secuencia de procesamiento local individual) y dar resultados imprevisibles en la producción dependiendo en la vida de tu hilo.

Ni el establecimiento del atributo de solicitud ni la manipulación de la sesión es seguro para la ejecución de subprocesos en mod_wsgi. Como process_response toma la solicitud como un argumento, debe realizar toda su lógica en esa función.

class ThreadsafeTestMiddleware(object): 

    def process_response(self, request, response): 
     thread_safe_variable = request.some_dynamic_value_from_request 
+0

Esto es incorrecto. Su objeto de solicitud/respuesta no se comparte entre subprocesos y/o solicitudes, por lo que es seguro de usar. –

+0

No funcionó para mí. Tuve casos en los que los datos de solicitud del primer usuario se establecieron durante la vigencia del hilo y causaron problemas. – roktechie

+0

El objeto de solicitud se crea al inicio de una solicitud y no se elimina hasta que la solicitud haya pasado por todas las clases de middleware, se haya manejado y haya vuelto a pasar a través de los middlewares. No tiene nada que ver con el enhebrado: es el mismo objeto no compartido durante todo el proceso. –

Cuestiones relacionadas