La sesión HTTP y las sesiones CometD tienen diferentes ciclos de vida: por ejemplo, si hay un error de conexión temporal, la sesión CometD fallará, y el servidor solicitará al cliente un nuevo intercambio, creando así un CometD diferente sesión (que representa al mismo usuario, pero con un CometD diferente clientId). En el mismo caso, el HttpSession seguirá siendo el mismo.
Teniendo esto en cuenta, debe mantener, a nivel de aplicación, una asignación entre un nombre de usuario, el corresponsal HttpSession, y el corresponsal ServerSession. Llamemos a este mapeo HttpCometDMapper. Cada vez que un nuevo usuario inicia sesión, usted registra su nombre (u otro identificador único del usuario), el HttpSession, y el actual ServerSession. Probablemente necesite un proceso de dos pasos, donde primero vincula el nombre de usuario y el HttpSession, y luego el mismo nombre de usuario con el ServerSession.
Si se realiza un nuevo apretón de manos CometD, actualice el asignador con el nuevo ServerSession.
puede vincular las dos sesiones al registrar un HttpSessionListener a la HttpSession de modo que cuando se destruye, se recupera la corriente CometD ServerSession desde el asignador y llamar ServerSession.disconnect() en él.
El viceversa es un poco más complicado porque CometD no tiene un concepto de tiempo de inactividad como HttpSession. Debe implementarse en la aplicación con su propia lógica.
Una parte de hacerlo es registrar un RemoveListener en el ServerSession, así:
serverSession.addListener(new ServerSession.RemoveListener()
{
public void removed(ServerSession session, boolean timeout);
{
if (!timeout)
{
// Explicitly disconnected, invalidate the HttpSession
httpCometDMapper.invalidate(session);
}
}
});
Este oyente relojes para desconexiones explícitas desde el cliente y el servidor (- cuidado de reentrada).
Un poco más difícil es implementar el mismo mecanismo para desconexiones no explícitas.En este caso, el parámetro timeout será verdadero, pero podría haber ocurrido debido a una falla temporal de la red (en lugar de que el cliente desaparezca para siempre), y el mismo usuario ya puede haber vuelto a apretones de manos con un nuevo ServerSession.
Creo que en este caso un tiempo de espera de la aplicación podría resolver el problema: cuando vea un ServerSession eliminado debido a un tiempo de espera, se fija en ese usuario y se inicia un tiempo de espera de la aplicación. Si el mismo usuario vuelve a apretones de manos, cancele el tiempo de espera de la aplicación; de lo contrario, el usuario se habrá ido, el tiempo de espera de la aplicación expirará e invalidará también el HttpSession.
Lo anterior son solo ideas y sugerencias; la implementación real depende en gran medida de los detalles de la aplicación (y es por eso que CometD no la proporciona de fábrica).
Los puntos clave son el asignador, el HttpSessionListener y el RemoveListener, y conocer los ciclos de vida de esos componentes. Una vez que lo administre, puede escribir el código correcto que haga lo correcto para su aplicación.
Por último, cabe destacar que CometD tiene una manera independiente del transporte de interactuar con el HttpSession a través de la BayeuxContext ejemplo, que se puede obtener de BayeuxServer.getContext(). Sugiero que lo mires también para ver si puede simplificar las cosas, especialmente para recuperar tokens almacenados en el HttpSession.