Beschreiben Sie im Detail den Management -Sitzungsmechanismus in Tomcat:
1. Sitzungsvorgang während des Anfrageprozesses:
Kurze Beschreibung: Während des Anforderungsprozesses analysieren Sie zuerst die SessionID -Informationen in der Anforderung und speichern Sie dann die Sitzung in der Parameterliste der Anforderung. Wenn Sie dann die Sitzung aus der Anfrage erhalten, erhalten Sie die Sitzung aus dem Sitzungspool basierend auf der ID. Wenn die Sitzung nicht vorhanden ist oder die Sitzung fehlschlägt, erstellen Sie eine neue Sitzung und legen Sie die Sitzungsinformationen für die nächste Verwendung in den Sitzungspool.
(1) Sessionid -Parsing -Prozess -Timing -Diagramm:
Übersicht: Zuerst sendet der Benutzer eine HTTP -Anfrage, um sie an HTTP11PROCESSOR weiterzuleiten und dann über http11Processor an Coyoteadapter weiterzugeben. Der Coyoteadapter ist ein Adapter, der die vom Coyote -Framework in org.apache.catalina.Connector.request eingekapselte org.apache.coyote.request angepasst hat (ich werde nicht viel über diesen Prozess sagen, der zuvor zusammengefasst wurde). Nach der Konvertierung wird die Parsepathparameters -Methode aufgerufen, um die Cookie -Informationen in den Pfadparametern zu analysieren (da das Cookie vom Browser deaktiviert wird, werden die Cookie -Informationen in die URL umgeschrieben). Versuchen Sie zunächst, die Sessionid von der URL zu analysieren. Dann wird die ParseSessioncookiesid aufgerufen. Dies soll die Sitzung vom Cookie analysieren und in der Anfrage speichern (Parsepathparameter und ParseSessioncookiesid -Methoden. Während des Anrufprozesses wird keine offensichtliche XOR -Logik gesehen, das heißt, beide werden ausgeführt. Problem). Der Analyse zur Sitzung und in die Anfrage eingerichtet. Es ist in Ordnung, die Logik der SessionID zu analysieren.
Die folgenden Schlüsselcodes werden veröffentlicht:
Parsepathparameters -Methode (analysiert aus der Rewrite -URL):
PS: Die markierten Teile analysieren Variablen aus der URL und setzen sie dann in die Liste der Anforderungsparameter.
ParseSessioncookiesid -Methode (Parsing SessionID von Cookies):
PS: Das obige Tag soll die Sitzung vom Cookie erhalten. Schauen Sie sich das erste Tag mit einem Anruf bei Sessionconfig.GetSessionCookIename (Kontext) an. Hier erhalten Sie einen Schlüssel der Standard -SessionID. Dieser Schlüssel wird in Sessionconfig definiert, und sein Wert ist jsessionID:
(2) Der Prozess der Erlangung der Sitzung aus der Anforderung erfolgt im Grunde genommen wie oben beschrieben. Schauen Sie sich dann den Prozess der Erlangung der Sitzung in Servlet an:
Übersicht: Appservlet ist ein Servlet, den wir uns selbst definieren. Wenn wir die Sitzung über Reqest erhalten, ist die aufgerufene HTTPServletRequest (eine Schnittstelle) tatsächlich RequestFacade (eine Fassade, die org.apache.catalina.connector.request zusammenfasst, und dann ruft RequestFacade die GetSession -Methode der realen Anfrage auf. Die spezifische Logik der Anfrage besteht darin, die GetManger -Methode des Kontextcontainers aufzurufen, um den Sitzungsmanager zu erhalten (Details des Sitzungsmanagers werden nachstehend beschrieben). Wenn die SessionID analysiert wurde, wird die FindSession -Methode aufgerufen, um die entsprechende Sitzung aus dem Sitzungsobjektpool zu erhalten. Andernfalls muss eine Sitzung neu erstellt und in den Sitzungsobjektpool platziert werden.
Die folgenden Schlüsselcodes werden veröffentlicht:
Die GetSession -Methode der Klasse RequestFacade:
Die GetSession -Methode der Klassenanforderung:
Die DogetSession -Methode der Klassenanforderung:
PS: Das erste Tag besteht darin, Sitzungsinformationen aus dem Sitzungsobjektpool basierend auf der Sitzung zu erhalten. Das zweite Tag besteht darin, ein neues Sitzungsobjekt zu erstellen, ohne die Sitzung zu analysieren.
Dies schafft eine neue Sitzung. Dieser Punkt beinhaltet die Erzeugung der neuen Sitzung. Der logische Schlüsselcode zum Generieren von SessionID ist in der GeneratessionS -Methode im Klassen -SessionID -Generator definiert:
Das obige ist der Prozess des Servlet -Erhalts der Sitzung. Die folgenden Details fassen zusammen, wie Tomcat die Sitzung verwaltet, dh das Kenntnis des Sitzungsmanagers.
2. Sitzungsmanagementmechanismus
Session Manager Definition: Die Sitzungsmanager -Komponente ist für die Verwaltung von Sitzungsobjekten verantwortlich, z. B. das Erstellen und Zerstören von Sitzungsobjekten.
Schauen wir uns zunächst ein Klassenvererbungsstrukturdiagramm des Sitzungsmanagers an (dies ist das Diagramm von tocmat7.x, und der Klassenerbschaftsmechanismus von Tomcat5 unterscheidet sich sehr davon):
Kurze Beschreibung: Im Folgenden fasst jede Kategorie nacheinander zusammen (siehe offizielle Website -Informationen):
(1) Manager: Definiert die grundlegende Schnittstelle, die einem bestimmten Container zugeordnet ist, um den Sitzungspool zu verwalten.
(2) Managerbase: Implementiert die Manager -Schnittstelle, die die Implementierung gemeinsamer Funktionen des Sitzungsmanagers bietet.
(3) StandardManager: Erben von ManagerBase, dem Standard -Sitzungsmanager (keine Konfiguration angeben, verwenden Sie dies standardmäßig). Es handelt sich um eine Nicht-Cluster-Implementierung von Tomcat-Verarbeitungssitzungen (dh der eigenständigen Version). Wenn Tomcat geschlossen ist, werden die Informationen zur Speichersitzung auf der Festplatte bestehen und als Sitzung gespeichert und beim erneuten Booten wiederhergestellt.
(4) PersistentManagerBase: Immerdiert von Managerbase, implementiert und definiert die grundlegenden Funktionen des Sitzungsmanagers Persistenz.
(5) PersistentManager: Von PersistentManagerbase ererbt. Die Hauptfunktion besteht darin, Leerlauf -Sitzungsobjekte (durch Festlegen der Zeitüberschreitungszeit) auf der Festplatte auszutauschen.
(6) ClusterManager: Es implementiert die Manager -Schnittstelle, und Sie sollten unter dem Klassennamen erraten werden. Dies ist der Manager, der die Clustersitzung verwaltet, und der Sitzungsmanager der obigen Standardmanager-Version sind relative Konzepte. Diese Klasse definiert die Replikations- und Freigabe -Schnittstelle von Sitzungen zwischen Klassen.
(7) ClusterManagerBase: Implementiert die ClusterManager -Schnittstelle und erbt von Managerbase. Diese Klasse implementiert den grundlegenden Betrieb der Sitzungsreplikation.
(8) BackupManager: Von ClusterManagerBase geerbt, eine Implementierung der Replikationsstrategie für die Replikationsstrategie zwischen Cluster. In den Sitzungsdaten befindet sich nur ein Sicherungsknoten, und alle Knoten im Cluster sind am Ort dieses Sicherungsknotens sichtbar. Dieses Design bietet einen Vorteil bei der Unterstützung heterogener Bereitstellungen.
(9) Deltamanager: Von ClusterManagerBase geerbt, eine Implementierung der Replikationsstrategie der Clustersitzung. Im Gegensatz zu BackupManager werden Sitzungsdaten an alle Mitgliederknoten im Cluster kopiert, wodurch alle Knoten im Cluster isomorph sein müssen und dieselbe Anwendung bereitgestellt werden muss.
Ergänzung: Lassen Sie es uns im Folgenden ausführlich zusammenfassen. In der PersistentManagerbase -Klasse gibt es einen variablen Mitgliederspeicher:
Die Speicherstrategie des persistenten Sitzungsmanagers wird durch dieses Store -Objekt definiert. Die Klassenvererbungsstruktur dieses Geschäfts lautet wie folgt:
Kurze Beschreibung: Der Schnittstellenspeicher und seine Beispiele bieten eine Reihe von Speicherstrategien für den Sitzungsmanager. Der Store definiert die grundlegende Schnittstelle, und der Speicherbasis bietet die grundlegende Implementierung. Die von der FileStore -Klasse implementierte Richtlinie besteht darin, die Sitzung in einer im Verzeichnis angegebenen Datei mit setDirectory () zu speichern und mit .Session zu enden. Die JDBCStore -Klasse speichert die Sitzung über JDBC in der Datenbank. Daher ist es notwendig, JDBCStore zu verwenden. Sie müssen die Methode setDriverName () und die Methode setConnectionUrl () aufrufen, um den Treibernamen und die Verbindungs -URL festzulegen.
3. Konfiguration im Zusammenhang mit Tomcat-Sitzungen
Fassen Sie die Konfiguration und Einstellungen zusammen, die sich auf die Sitzung aus zwei Ebenen beziehen. Erstens hat die Sitzung auf der Ebene der Konfigurationsdatei eine Ablaufzeit und die Standardablaufzeit ist in $ catalina_home/conf/web.xml definiert. Die spezifische Standardkonfiguration ist wie folgt (die Standard -Ablaufzeit beträgt 30 Minuten, dh in 30 Minuten gibt es keinen Zugriff und die Sitzung läuft ab):
Ein weiterer Punkt ist, dass StandardManager standardmäßig verwendet wird, wenn die Sitzungsverwaltung nicht konfiguriert ist. Wenn Sie es jedoch konfigurieren möchten, können Sie es in $ catalina_home/conf/context.xml angeben (aus dieser Konfiguration können Sie feststellen, dass der Sitzungsmanager dem Kontext -Container zugeordnet ist, was bedeutet, dass jede Webanwendung über einen Sitzungsmanager verfügt). Die spezifische Konfiguration ist wie folgt:
Tomcat7.x standardmäßig zur Konfiguration dieses Managers. Wenn der PersistentManager, den Sie angeben möchten, der Standard -Manager ist, können Sie ihn so angeben:
Nachdem ich dies gesehen hatte, stellte ich fest, dass der Sitzungsmanager oder die Speicherspeicherrichtlinie angepasst werden kann, solange die relevante Schnittstelle implementiert ist. Es ist in Ordnung, hier selbst eine Konfiguration zu schreiben.
Lassen Sie uns außerdem von der Codeebene zusammengefasst: Einige Konfigurationsinformationen der Sitzung werden in den Code geschrieben, beispielsweise definiert die Sitzungskursklasse einige Sitzungseinstellungen. Der Name der Sitzung im Cookie ist Jsession. Wenn die Sitzung durch URL -Umschreiben auf dem Weg platziert wird, lautet der Name des Schlüsselwerts JSESSIONIDS. Der spezifische Code lautet wie folgt:
Ein weiterer Punkt besteht
OK, so viel wird über die Standardkonfiguration zusammengefasst.
Das obige ist der gesamte Inhalt dieses Artikels. Ich hoffe, es wird für das Lernen aller hilfreich sein und ich hoffe, jeder wird Wulin.com mehr unterstützen.