Con Play 1.0, teníamos el método session.getId() para recuperar un identificador de sesión único.¿Dónde está session.id en Play 2.0?
La identificación era útil para prefijar las claves en la caché global.
¿Dónde está Play 2.0 session.id equivalent?
Dado que los datos de la sesión se almacenan como cookies, no hay más id. De sesión con play 2.0. De hecho, tampoco hay necesidad de un token de identificación, los datos de la sesión simplemente se pasan junto con cada solicitud, dejando el servidor completamente sin estado.
Sin embargo, es posible que aún necesite una identificación si necesita almacenar datos por usuario en la memoria caché global. Para ello, utilice el código de abajo Identificación del
// Generate a unique id
String uuid=session("uuid");
if(uuid==null) {
uuid=java.util.UUID.randomUUID().toString();
session("uuid", uuid);
}
Sesión? suena tan Java EE de todos modos ...
¿Cómo se controla el ciclo de vida de los objetos en la memoria caché global? ¿Configura TTL y otros parámetros de caducidad? –
El ciclo de vida depende de la implementación de la memoria caché. No sé los detalles, si recuerdo que EHCache usa WeakReferences que se borran cuando la JVM requiere memoria. EHCache es una de las mejores API para el almacenamiento en caché, estoy seguro de que admiten configuración de caducidad. –
Ok, pero ¿qué es tan fundamentalmente diferente/mejor en Play 2.0? Una sesión (en general) es solo una tienda con un cierto ciclo de vida. El "problema de estado" está causado por detalles de implementación. –