Objeto compartido entre peticiones en Django.

Estoy usando un módulo Python ( PyCLIPS ) y Django 1.3.

Quiero desarrollar una clase de seguridad de subprocesos que realice el Grupo de objetos y los patrones Singleton y también que se deban compartir entre solicitudes en Django.

Por ejemplo, quiero hacer lo siguiente:

  • Una solicitud obtiene el objeto con algún ID del grupo, haga algo con él y vuelva a enviarlo al grupo, luego envíe la respuesta con el ID del objeto.
  • Otra solicitud, que tiene la ID del objeto, obtiene el objeto con la ID dada de la agrupación y repite los pasos de la solicitud anterior.
  • Pero el estado del objeto debe mantenerse mientras que estará en el grupo mientras el servidor se está ejecutando.

Debería ser como un bean de sesión Singleton en Java EE.

¿Cómo debo hacerlo? ¿Hay algo que deba leer?

Actualización: no puedo almacenar objetos del grupo en una base de datos, porque estos objetos son envoltorios en una biblioteca escrita en lenguaje C, que es la API para los CLIPS de Expert System Engine .

¡Gracias!

Bueno, creo que es necesario un ángulo diferente aquí. Django no es como Java, la solución debe adaptarse a un entorno de múltiples procesos, no a múltiples hilos.

Django no tiene equivalente inmediato de un bean de sesión de singleton.

Dicho esto, no veo por qué su descripción no se ajusta a un modelo de base de datos clásico. Desea guardar datos por objeto, que siempre deben ir en la capa DB.

De lo contrario, siempre puede guardar cosas en la sesión, que Django proporciona tanto a los usuarios registrados como a los anónimos; consulte la documentación sobre las sesiones de Django .

El uso de cualquier otro patrón con el que pueda estar familiarizado en un entorno Java finalmente fracasará, considerando la gran diferencia entre ejecutar un contenedor web Java y el entorno multiproceso Python / Django.


Edición: bueno, teniendo en cuenta que estos objetos no son nativos de su aplicación sino que se accede a ellos a través de una biblioteca de terceros, complica las cosas. Mi intuición es que estos objetos no deben ser manejados por la capa web, sino por algún tipo de servicio externo al que se puede acceder desde un entorno de múltiples procesos. Como lo mencionó Daniel, siempre puedes colocarlos en el caché (si dichos objetos son capaces de decaparse). Pero se siente como si estos objetos no pertenecieran al nivel web.

Suponiendo que el objeto no pueda ser decapado, deberá crear una aplicación para administrar el objeto y todas las interacciones que deben ocurrir en su contra. Probablemente, la implementación más sencilla sería crear una aplicación wsgi de un solo proceso (en un puerto diferente) que exponga una api para que realice todas las operaciones que necesite. Si usa una API RESTful o publicaciones de formularios depende de sus preferencias personales.

¿Son estos objetos de base de datos? Porque, de ser así, la propia db es realmente la agrupación, y no hay necesidad de hacer nada especial: cada solicitud puede cargar la instancia de forma independiente desde la db, modificarla y guardarla.

Editar después del comentario Bueno, el mayor problema es que un entorno de servidor web de producción probablemente sea multiproceso, por lo que las variables globales (es decir, el grupo) no se comparten entre procesos. Deberá almacenarlos en un lugar accesible globalmente. Un corto en la oscuridad, ¿pero son serializables utilizando Pickle? Si es así, entonces quizás funcione memcache.