Describa en detalle el mecanismo de gestión de la sesión en Tomcat:
1. Operación de sesión durante el proceso de solicitud:
Breve descripción: Durante el proceso de solicitud, primero analice la información de SessionID en la solicitud y luego almacene el SessionID en la lista de parámetros de la solicitud. Luego, cuando obtenga la sesión de la solicitud, si el INS SessionD existe, obtendrá la sesión del grupo de sesión en función de la identificación. Si el SessionId no existe o la sesión falla, cree una nueva sesión y coloque la información de la sesión en el grupo de sesión para el próximo uso.
(1) Diagrama de tiempo del proceso de análisis de sesión de sesión:
Descripción general: Primero, el usuario envía una solicitud HTTP para pasarla a HTTP11processor, y luego la pasa a CoyoteAdapter a través de HTTP11processor. El CoyoteadApter es un adaptador que adapta el org.apache.coyote.Request encapsulado por el marco Coyote a org.apache.catalina.connector.request (no diré mucho sobre este proceso, lo que se ha resumido antes). Después de la conversión, se llamará al método ParsePathParameters para analizar la información de las cookies en los parámetros de ruta (porque cuando el navegador desactive la cookie, la información de la cookie se reescribirá en la URL). Primero, intente analizar la sesión de Session de la URL. Entonces se llamará al parsesessioncookiesid. Esto es para analizar la sesión de la cookie y almacenarla en la solicitud (ParsePathParameters y ParSesessioncookiesid. ningún problema). El análisis del SessionID y lo ponga en la solicitud. Está bien analizar la lógica de SessionID.
Se publican los siguientes códigos clave:
Método ParsePathParameters (analizado de la URL de reescritura):
PS: Las partes marcadas son variables de análisis de la URL y luego las colocan en la lista de parámetros de solicitud.
Método ParsesessionCookiesID (SessionID de análisis de cookies):
PD: La etiqueta anterior es obtener la sesión de sesión de la cookie. Mire la primera etiqueta con una llamada a sessionconfig.getSessionCookiename (contexto), aquí obtendrá una clave del SessionID predeterminado. Esta clave se define en SessionConfig, y su valor es JSesionID:
(2) El proceso de obtención de la sesión de la solicitud es básicamente como se describe anteriormente. Luego eche un vistazo al proceso de obtención de la sesión en Servlet:
Descripción general: AppServlet es un servlet que nos definimos. Cuando obtenemos la sesión a través de Reqest, el httpservletRequest (una interfaz) que se llama es realmente requestfacade (una fachada que encapsula org.apache.catalina.connector.request), y luego requestfacade llamará al método de getsession de la solicitud real. La lógica específica de la solicitud es llamar al método GetManger del contenedor de contexto para obtener el administrador de sesión (los detalles del administrador de la sesión se describen a continuación). Si se ha analizado el INSEGIDO, entonces se llamará al método FindSession para obtener la sesión correspondiente del grupo de objetos de sesión. De lo contrario, si el SessionId no existe, una sesión debe recrearse y colocarse en el grupo de objetos de sesión.
Se publican los siguientes códigos clave:
El método de getsession de la solicitud de clasesfacade:
El método de solicitud de clase de getsession:
El método de la solicitud de clase de DoGetSession:
PD: La primera etiqueta es obtener información de sesión del grupo de objetos de sesión basado en SessionID, y la segunda etiqueta es crear un nuevo objeto de sesión sin analizar el SessionID.
Esto crea una nueva sesión. Este punto implica la generación del nuevo SessionID. El código de clave lógico para generar sesiónid se define en el método GeneratesSessionId en el generador de clases SessionID:
Lo anterior es el proceso de sesión de obtención de servlet. Los siguientes detalles resumen cómo Tomcat administra la sesión, es decir, el conocimiento del gerente de sesión.
2. Mecanismo de gestión de sesiones
Definición del administrador de sesiones: el componente del administrador de sesiones es responsable de administrar objetos de sesión, como crear y destruir objetos de sesión.
Primero, veamos un diagrama de estructura de herencia de clase del administrador de la sesión (este es el gráfico de ToCMAT7.X, y el mecanismo de herencia de clase de TOMCAT5 es muy diferente de esto):
Breve descripción: Lo siguiente resume cada categoría a su vez (consulte la información oficial del sitio web):
(1) Administrador: Define la interfaz básica asociada con un determinado contenedor para administrar el grupo de sesión.
(2) ManagerBase: implementa la interfaz del administrador, que proporciona la implementación de funciones comunes del administrador de sesiones.
(3) StandardManager: hereda de ManagerBase, el administrador de sesión predeterminado (sin especificar la configuración, use esto de forma predeterminada). Es una implementación que no es de clúster de las sesiones de procesamiento TomCat (es decir, la versión independiente). Cuando Tomcat esté cerrado, la información de la sesión de memoria persistirá en el disco y se guardará como session.ser, y se restaurará al arrancar nuevamente.
(4) PersistentManagerBase: heredado de ManagerBase, implementa y define las funciones básicas de la persistencia del gerente de sesión.
(5) Managente persistente: heredado de PersistentManagerBase. La función principal es intercambiar objetos de sesión inactivos (estableciendo el tiempo de tiempo de espera) en el disco.
(6) ClusterManager: implementa la interfaz del administrador, y debe ser adivinado por el nombre de la clase. Este es el gerente que administra la sesión de clúster y el gerente de sesión de la versión independiente StandardManager anterior son conceptos relativos. Esta clase define la interfaz de replicación e intercambio de sesiones entre clases.
(7) ClusterManagerBase: implementa la interfaz ClusterManager y hereda de ManagerBase. Esta clase implementa el funcionamiento básico de la replicación de la sesión.
(8) BackupManager: Heredado de ClusterManagerBase, una implementación de la estrategia de replicación de sesión entre clúster. Solo hay un nodo de copia de seguridad en los datos de la sesión, y todos los nodos en el clúster están visibles en la ubicación de este nodo de copia de seguridad. Este diseño le da una ventaja para soportar implementaciones heterogéneas.
(9) Deltamanager: heredado de ClusterManagerBase, una implementación de la estrategia de replicación de la sesión de clúster. A diferencia de BackupManager, los datos de la sesión se copiarán en todos los nodos miembros en el clúster, lo que requiere que todos los nodos en el clúster sean isomórficos y la misma aplicación debe implementarse.
Suplemento: resumamos en detalle a continuación. Hay una tienda variable miembro en la clase PersistentManagerBase:
La estrategia de almacenamiento del gerente de sesión persistente está definida por este objeto de la tienda. La estructura de herencia de clase de esta tienda es la siguiente:
Breve descripción: La tienda de interfaz y sus ejemplos proporcionan un conjunto de estrategias de almacenamiento para el administrador de sesiones. La tienda define la interfaz básica, y StoreBase proporciona la implementación básica. La política implementada por la clase Filestore es almacenar la sesión en un archivo especificado en el directorio con setDirectory () y terminar con .session. La clase JDBCSTORE almacena la sesión en la base de datos a través de JDBC. Por lo tanto, es necesario usar JDBCStore. Debe llamar al método setDrivername () y el método setconnectionUrl () respectivamente para establecer el nombre del controlador y la URL de conexión.
3. Configuración relacionada con la sesión de Tomcat
Resume la configuración y la configuración relacionadas con la sesión de dos niveles. En primer lugar, desde el nivel de archivo de configuración, la sesión tiene un tiempo de vencimiento, y el tiempo de vencimiento predeterminado se define en $ catalina_home/conf/web.xml. La configuración predeterminada específica es la siguiente (el tiempo de vencimiento predeterminado es de 30 minutos, es decir, no hay acceso en 30 minutos y la sesión expira):
Otro punto es que si la administración de la sesión no está configurada, StandardManager se usa de forma predeterminada. Sin embargo, si desea configurarlo, puede especificarlo en $ catalina_home/conf/context.xml (desde esta configuración, puede ver que el administrador de sesión está asociado con el contenedor de contexto, lo que significa que cada aplicación web tendrá un administrador de sesión). La configuración específica es la siguiente:
TomCat7.x predeterminado es la configuración de este administrador. Si el PersistentManager que desea especificar es el administrador predeterminado, puede especificarlo así:
De hecho, después de ver esto, descubrí que el administrador de sesiones o la política de almacenamiento de la tienda se pueden personalizar siempre que se implementen la interfaz relevante. Está bien escribir una configuración usted mismo aquí.
Además, resumamos desde el nivel de código: alguna información de configuración de la sesión se escribe en el código, por ejemplo, la clase SessionConfig define alguna información de configuración de sesión. El nombre de la sesión en la cookie es jsession. Cuando la sesión se coloca en la ruta a través de la reescritura de URL, el nombre del valor clave es JSessionIds. El código específico es el siguiente:
Otro punto es que la longitud especificada predeterminada de SessionID es 16 bytes, que se especifica en el SessionIdGenerator:
Ok, se resume mucho sobre la configuración predeterminada.
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.