Décrivez en détail le mécanisme de gestion de la session dans Tomcat:
1. Fonctionnement de la session pendant le processus de demande:
Brève description: Pendant le processus de demande, analysez d'abord les informations de sessionID dans la demande, puis stockez le SessionID dans la liste des paramètres de la demande. Ensuite, lorsque vous obtenez la session à partir de la demande, si le sessionID existe, vous obtiendrez la session du pool de session en fonction de l'ID. Si le SessionID n'existe pas ou si la session échoue, créez une nouvelle session et placez les informations de session dans le pool de session pour la prochaine utilisation.
(1) Diagramme de synchronisation du processus d'analyse de session:
Présentation: Tout d'abord, l'utilisateur envoie une demande HTTP pour la transmettre à HTTP11Processor, puis la transmet à Coyoteadapter via HTTP11Processor. Le coyoteadapter est un adaptateur qui adapte le framework org.apache.coyote. Après la conversion, la méthode des parsepathParameters sera appelée pour analyser les informations sur les cookies dans les paramètres de chemin (car lorsque le cookie est désactivé par le navigateur, les informations sur les cookies seront réinsérises dans l'URL). Tout d'abord, essayez d'analyser le SessionId à partir de l'URL. Ensuite, le ParsessionCookesid sera appelé. Il s'agit d'analyser le sessionId à partir du cookie et de le stocker dans la demande (ParsepathParameters et ParsesessionCooKiesid Methods. Pendant le processus d'appel, aucune logique XOR évidente n'est vue, c'est-à-dire que les deux sont exécutés, mais n'y a-t-il pas de problème? aucun problème). L'analyse du SessionId et la mettent dans la demande. Il est normal d'analyser la logique de SessionId.
Les codes clés suivants sont publiés:
Méthode des parsepathParameters (analysé à partir de l'URL de réécriture):
PS: les pièces marquées sont des variables d'analyse de l'URL, puis les mettent dans la liste des paramètres de demande.
Méthode PARSESSESSECOOKIESID (Sessiond SessionId à partir de cookies):
PS: La balise ci-dessus est d'obtenir le SessionId à partir du cookie. Regardez la première balise avec un appel à SessionConfig.getSessionCookiename (Context), vous obtiendrez ici une clé de la session par défaut. Cette clé est définie dans SessionConfig, et sa valeur est JSessionID:
(2) Le processus d'obtention de session à partir de la demande est essentiellement comme décrit ci-dessus. Jetez ensuite un œil au processus d'obtention de la session en servlet:
Aperçu: Appservlet est un servlet que nous nous définissons. Lorsque nous obtenons la session via REQEST, la HttpServLetRequest (une interface) qui est appelée est en fait requestfacade (une façade qui résume org.apache.catalina.connector.request), puis Dequefacade appellera la méthode Getession de la demande réelle. La logique spécifique de la demande est d'appeler la méthode GetManger du conteneur de contexte pour obtenir le gestionnaire de session (les détails du gestionnaire de session sont décrits ci-dessous). Si le SessionID a été analysé, la méthode FindSession sera appelée pour obtenir la session correspondante à partir du pool d'objets de session. Sinon, si le SessionID n'existe pas, une session doit être recréée et placée dans le pool d'objets de session.
Les codes clés suivants sont publiés:
La méthode GETSESSION de la classe DemandeFacade:
La méthode Getession de la demande de classe:
La méthode DoGetSession de la demande de classe:
PS: La première balise consiste à obtenir des informations de session à partir du pool d'objets de session en fonction du SessionID, et la deuxième balise consiste à créer un nouvel objet de session sans analyser le sessionID.
Cela crée une nouvelle session. Ce point implique la génération du nouveau sessionID. Le code de clé logique pour la génération de sessionID est défini dans la méthode GeneraSesSessionID dans le générateur de SessionID de classe:
Ce qui précède est le processus de session d'obtention du servlet. Les détails suivants résument comment Tomcat gère la session, c'est-à-dire la connaissance du gestionnaire de session.
2. Mécanisme de gestion des sessions
Définition du gestionnaire de session: Le composant Session Manager est responsable de la gestion des objets de session, tels que la création et la destruction d'objets de session.
Tout d'abord, examinons un diagramme de structure d'héritage de classe du gestionnaire de session (il s'agit du graphique de TOCMAT7.x, et le mécanisme de succession de la classe de TomCat5 est très différent de cela):
Brève description: la suivante résume chaque catégorie à son tour (reportez-vous aux informations officielles du site Web):
(1) Manager: définit l'interface de base associée à un certain conteneur pour gérer le pool de session.
(2) ManagerBase: implémente l'interface Manager, qui fournit la mise en œuvre des fonctions communes du gestionnaire de session.
(3) StandardManager: Hérite de ManagerBase, le Session Manager par défaut (sans spécifier la configuration, utilisez-le par défaut). Il s'agit d'une implémentation non-cluster des séances de traitement TOMCAT (c'est-à-dire la version autonome). Lorsque Tomcat est fermé, les informations de session de mémoire seront persistées sur le disque et enregistrées en tant que session.ser, et seront restaurées lors du démarrage à nouveau.
(4) PersistantManagerBase: Hérité de ManagerBase, implémente et définit les fonctions de base de la persistance du gestionnaire de session.
(5) PersistantManager: Hérité de PersistantManagerbase. La fonction principale est d'échanger des objets de session inactifs (en définissant le temps de temps mort) sur le disque.
(6) ClusterManager: il implémente l'interface du gestionnaire, et vous devez être deviné par le nom de la classe. Il s'agit du gestionnaire qui gère la session de cluster et le gestionnaire de session de la version autonome StandardManager ci-dessus sont des concepts relatifs. Cette classe définit l'interface de réplication et de partage des sessions entre les classes.
(7) ClusterManagerBase: implémente l'interface ClusterManager et hérite de ManagerBase. Cette classe met en œuvre le fonctionnement de base de la réplication de la session.
(8) BackupManager: Hérité de ClusterManagerBase, une implémentation de la stratégie de réplication de la session intercluster. Il n'y a qu'un seul nœud de sauvegarde dans les données de session, et tous les nœuds du cluster sont visibles à l'emplacement de ce nœud de sauvegarde. Cette conception lui donne un avantage à soutenir les déploiements hétérogènes.
(9) Deltamanager: Hérité de ClusterManagerBase, une implémentation de la stratégie de réplication de la session de cluster. Contrairement à BackupManager, les données de session seront copiées sur tous les nœuds membres du cluster, ce qui nécessite que tous les nœuds du cluster doivent être isomorphes et que la même application doit être déployée.
Supplément: Résumons-le en détail ci-dessous. Il existe un magasin de variables de membre dans la classe PersistantManagerBase:
La stratégie de stockage du gestionnaire de session persistant est définie par cet objet de magasin. La structure de succession de la classe de ce magasin est la suivante:
Brève description: Le magasin d'interface et ses exemples fournissent un ensemble de stratégies de stockage pour le gestionnaire de session. Le magasin définit l'interface de base et le magasin fournit l'implémentation de base. La politique implémentée par la classe FileStore est de stocker la session dans un fichier spécifié dans le répertoire avec setDirectory () et se terminer par .Session. La classe JDBCStore stocke la session dans la base de données via JDBC. Par conséquent, il est nécessaire d'utiliser JDBCStore. Vous devez appeler la méthode setDrivername () et la méthode setConnectionUrl () respectivement pour définir le nom du pilote et l'URL de connexion.
3. Configuration liée à la session Tomcat
Résumez la configuration et les paramètres liés à la session à partir de deux niveaux. Tout d'abord, à partir du niveau du fichier de configuration, la session a un temps d'expiration et le temps d'expiration par défaut est défini dans $ Catalina_home / conf / web.xml. La configuration par défaut spécifique est la suivante (le temps d'expiration par défaut est de 30 minutes, c'est-à-dire qu'il n'y a pas d'accès dans 30min et la session expire):
Un autre point est que si la gestion de session n'est pas configurée, StandardManager est utilisé par défaut. Cependant, si vous souhaitez le configurer, vous pouvez le spécifier dans $ Catalina_Home / Conf / context.xml (à partir de cette configuration, vous pouvez voir que le gestionnaire de session est associé au conteneur de contexte, ce qui signifie que chaque application Web aura un gestionnaire de session). La configuration spécifique est la suivante:
Tomcat7.x par défaut la configuration de ce gestionnaire. Si le manager persistant que vous souhaitez spécifier est le gestionnaire par défaut, vous pouvez le spécifier comme ceci:
En fait, après avoir vu cela, j'ai découvert que le gestionnaire de session ou la politique de stockage de magasin peut être personnalisé tant que l'interface pertinente est implémentée. Il est normal d'écrire une configuration vous-même ici.
En outre, résumons à partir du niveau de code: certaines informations de configuration de la session sont écrites dans le code, par exemple, la classe SessionConfig définit certaines informations de paramètre de session. Le nom de la session dans le cookie est JSession. Lorsque la session est placée dans le chemin par la réécriture de l'URL, le nom de la valeur clé est JSessionID. Le code spécifique est le suivant:
Un autre point est que la longueur spécifiée par défaut de SessionID est de 16 octets, qui est spécifié dans le SessionIdGenerator:
Ok, tant de choses sont résumées sur la configuration par défaut.
Ce qui précède est tout le contenu de cet article. J'espère que cela sera utile à l'apprentissage de tous et j'espère que tout le monde soutiendra davantage Wulin.com.