App Engine/Django - cross - Processing multiple requests that interfere with GAE sessions

Descripción del problema

estoy usando Django para ejecutar aplicaciones Python en el motor de aplicaciones. Además, estoy usando una biblioteca de gestión de sesiones llamada gae-sessions. Si threadsafe está configurado a "no", no hay problema, pero cuando threadsafe está configurado a "yes", ocasionalmente veo un problema de pérdida de sesión.
El problema que veo es que cuando se activa la estampida, múltiples solicitudes se cruzan localmente en el middleware de sesión GAE.
En la Biblioteca gae-sessions, hay una variable llamada _tls, que es una variable threading.local(). Cuando un usuario envía una solicitud http a un sitio web, primero ejecuta una función llamada process_request(), luego genera una serie de html personalizados para la página actual, y luego ejecuta una función llamada process_response(). En la variable process_request "thread Security", se recuerda el Estado entre process_response y _tls. Puedo comprobar la singularidad de la variable _tls imprimiendo el valor _tls (por ejemplo, "<thread._local object at 0xfc2e8de0>").
Lo que he visto ocasionalmente es que en el middleware GAE sessions parece haber sólo un hilo (infiriendo que son un solo hilo) múltiples peticiones http se entrelazan, ya que tienen la misma ubicación de memoria para el objeto thread local, y los datos de una solicitud parecen sobrescribir los datos de otra solicitud. Dado que el usuario 1 y el usuario 2 envían solicitudes al mismo tiempo, he sido testigo del siguiente orden de ejecución:
User1 -> `process_request` is executed on thread A
User2 -> `process_request` is executed on thread A
User2 -> `process_response` is executed on thread A
User1 -> `process_response` is executed on thread A
En el escenario anterior, la sesión user2 PISA algunas variables internas, causando que la sesión user1 se pierda.
Por consiguiente, mi pregunta es la siguiente:
¿Es el entrelazamiento de diferentes solicitudes en middleware el comportamiento esperado en App Engine/Django/Python? (o estoy completamente confundido, algo más está pasando aquí.)
¿A qué nivel ocurre este entrelazamiento (App Engine/Django/Python)?
Me sorprendió ver este comportamiento, así que estoy interesado en saber lo que está pasando aquí.

Solución de referencia

encontré los siguientes enlaces para ayudar a entender lo que está pasando:
  • http://blog.notdot.net/2011/10/Migrating-to-Python-2-7-part-1-Threadsafe
  • Is Django middleware thread safe?
  • http://blog.roseman.org.uk/2010/02/01/middleware-post-processing-django-gotcha/
  • Supongamos que tengo una comprensión correcta de todo lo que está pasando por las siguientes razones:
    Cuando Django se ejecuta, ejecuta la mayoría de las funciones básicas en el hilo padre (público) que contiene el middleware Django.
    Una sola solicitud se ejecuta en un hilo hijo que puede interactuar con el hilo padre.
    Como resultado de lo anterior, las solicitudes (sub - hilos) realmente se entrelazan en el middleware - que está diseñado (ejecutando sólo una copia de django, middleware ahorra memoria, mejora la eficiencia, etc.). [vea mi primer artículo enlazado en esta respuesta para una rápida comprensión de cómo los hilos Interact úan con los procesos hijo/padre]
    Con respecto a GAE-Sessions, el hilo que estamos comprobando es el mismo para diferentes solicitudes porque es el hilo padre (común a todos los hilos/peticiones hijo), no el hilo hijo que vemos cada vez que entramos en el middleware.GAE-Sessions está almacenando datos de Estado en el middleware, y dado que los hilos hijo en el hilo padre (Django + middleware) pueden estar entrelazados, diferentes solicitudes pueden anular los datos de Estado. La solución que apliqué a GAE-Sessions fue almacenar todos los datos de Estado en el objeto de solicitud, no en middleware.
    Fix: anteriormente, las referencias escribibles a las funciones del controlador de respuesta se almacenaban como DjangoSessionMiddlware en el objeto self.response_handlers, que he movido al objeto de solicitud request.response_handlers. También Eliminé la variable _tls y moví los datos que contenía al objeto request.