Dieser Artikel stellt hauptsächlich das Funktionsprinzip der Servlet-Sitzung vor. Der Herausgeber findet es ziemlich gut. Jetzt werde ich es mit Ihnen teilen und es als Referenz geben. Folgen wir dem Editor und werfen wir einen Blick darauf
Um das zugrunde liegende Funktionsprinzip von Session zu verstehen. Schauen wir uns zunächst die Situation an, in der derselbe Browser während einer Sitzung auf mehrere Webressourcen zugreift. Dies kann grob in die folgenden Schritte unterteilt werden:
1 Der Browser greift zu diesem Zeitpunkt auf ein Servlet zu Der Server möchte das Sitzungsobjekt vom Anforderungsobjekt erhalten (die erste Erfassung wird ebenfalls erstellt), dann erstellt der Server eine ID für dieses Sitzungsobjekt: JSESSIONID
2 und gleichzeitig , der Browser Während des Antwortvorgangs sendet diese Sitzung die ID JSESSIONID in Form eines Cookies an den Client-Browser zurück. Beachten Sie, dass der Cookie-Server zu diesem Zeitpunkt keine gültige Zeit festgelegt hat und daher im Browser gespeichert wird Cache, nicht in der Festplattendatei.
3. Wenn der Benutzer während dieser Sitzung weiterhin auf andere Servlets zugreift, ruft das Servlet das Sitzungsobjekt vom Anforderungsobjekt ab. Beachten Sie, dass das Abrufen des Sitzungsobjekts zu diesem Zeitpunkt eine vom Abfrage, ob ein Cookie mit dem Namen JSESSIONID vorhanden ist, muss die Sitzung nicht erneut erstellt werden, sondern fragt direkt die Sitzung mit demselben JSESSIONID-Wert auf dem Server ab Die Sitzung kann abgerufen werden.
Zusammenfassend lässt sich sagen, dass die Sitzung auf Cookies basiert.
(Hinweis: Cookies sind nicht allmächtig. Session verlässt sich zunächst auf Cookies, aber manchmal können Cookies nicht verwendet werden. Zu diesem Zeitpunkt prüft Session, ob die von der Anfrage gesendete URL-Adresse eine JSESSIONID hat.)
Sessions versteckte Cookies, wir können ein kleines Experiment durchführen, um es zu überprüfen. Erstellen Sie zwei Servlets unter dem [myservlet]-Webprojekt mit den Namen SessionDemo1 bzw. SessionDemo2:
Die Code in SessionDemo1 ist:
HttpSession session = request.getSession(); String data = "Message from SessionDemo"; session.setAttribute("data", data);
Der Code in SessionDemo2 ist:
HttpSession session = request.getSession(); System.out.println((String)session.getAttribute("data"));
Wir öffnen HttpWatch im Browser, um auf SessionDemo1 zuzugreifen. Da dies das erste Mal ist, dass auf das Servlet zugegriffen wird, überprüfen Sie die Antwort von SessionDemo1 an den Browser:
Bestätigen Sie, dass der Server ein Cookie mit diesem JSESSIONID-Namen an den Browser zurücksendet. Wenn wir zu diesem Zeitpunkt im geöffneten Browser auf SessionDemo2 zugreifen, beobachten Sie den Inhalt des Anforderungspakets in HttpWatch und finden Sie:
Wenn Sie den Server erneut besuchen, bringt der Browser dieses Cookie mit dem Namen JSESSIONID zum Server. Der Server verwendet den JSESSIONID-Wert in diesem Cookie, um die zuvor für den Browser auf dem Server erstellte Sitzung zu finden .
Wenn wir den Browser schließen, existiert dieses Cookie nur im Puffer des Browsers und wird zerstört, wenn der Browser geschlossen wird, da für dieses Cookie nicht „setMaxAge“ gesetzt ist. Wenn wir möchten, dass die Sitzung nach dem Schließen des Browsers noch vorhanden ist, müssen wir das Sitzungscookie manuell überschreiben und die Gültigkeitsdauer und den effektiven Pfad des Überschreibungscookies festlegen. Der Wert dieses Cookies, der der Wert von JSESSIONID ist, kann über die getId()-Methode von Session abgerufen werden.
1, gültige Abdeckungszeit:
Beachten Sie, dass der Server keine Sitzung mehr ausführen kann, nachdem er eine Sitzung für den Browser erstellt hat Wird vom Benutzer standardmäßig 30 Minuten lang beibehalten (oder nachdem der Browser geschlossen wurde) . Dies ist aus der Datei [web.xml] von Tomcat ersichtlich:
Natürlich können wir von hier aus auch die standardmäßige Zerstörung der Sitzung ohne Betrieb ändern .
Wenn wir die Zerstörungszeit der Sitzung nicht auf allen Servern global festlegen möchten, können wir
Hinweis: Wir können eine Sitzung auch sofort über die invalidate()-Methode des Session-Objekts zerstören.
Wenn wir in diesem Zusammenhang ein Sitzungscookie überschreiben und in einer Festplattendatei speichern möchten, sollte die von uns festgelegte Cookie-Gültigkeitszeit die standardmäßige Sitzungs-Timeout-Zeit des Servers nicht überschreiten.
2, Abdeckung des effektiven Pfads:
Wenn wir ein Cookie-Objekt erstellen und nicht „setPath“ festlegen, dann ist der effektive Pfad von Das Cookie dient dazu, das Cookie-Programm (normalerweise ein Servlet) zu erstellen, das heißt, der Browser trägt das Cookie nur dann mit sich, wenn auf dieses Programm zugegriffen wird. Das ist wirklich „unverbunden“ und die Sitzung kann nicht für den Zugriff auf andere Ressourcen verwendet werden diese Webanwendung.
Werfen wir einen Blick auf den effektiven Pfad des Cookies in der Sitzung, die vom Server für den Browser erstellt wurde, als wir zum ersten Mal auf das Servlet zugegriffen haben:
可以看到这个服务器默认将JSESSIONID这个cookie的有效路径设置为创建这个Session的web工程根目录。所以我们要覆盖Session中的cookie时也应该设置路径为该web工程根目录。
好,接下来对上面那个Servlet的例子进行改造,我们只需要在SessionDemo1中修改就行,因为这个首次将Session的cookie返回给客户端,修改后代码如下:
HttpSession session = request.getSession(); String data = "Message from SessionDemo"; session.setAttribute("data", data); Cookie cookie = new Cookie("JSESSIONID", session.getId()); cookie.setMaxAge(30*60); cookie.setPath("/myservlet"); response.addCookie(cookie);
这样,当我们打开浏览器访问了SessionDemo1之后,就能在存放cookie的目录中找到该cookie,如果我们通过HttpWatch来查看可以看到重名的这个cookie:
虽然JSEESIONID这个cookie重名了,没有关系,因为其值都是一样的,并且如果我们将浏览器关闭后,没有设置cookie有效时间的(也是原先Session发来的)cookie将不复存在(存在浏览器缓存中,浏览器关闭就被销毁),这时重新打开一个浏览器,再去访问SessionDemo2依然能获取到原来Session中保存的内容:
注意,这是另外打开浏览器窗口访问的SessionDemo2!!另附:
通过这里我们可以看到,我们人为地将原先Session定义的cookie给替换了,而Session并不知道,只要能获得“JSESSIONID”这个cookie,它就认为cookie是存在的,可以从这个cookie中id值获取以前保存的信息,因此我们实现了一台主机共享一个Session,此时,当浏览器关闭,或者说结束一个会话后,依然能获取Session来获取之前保存的数据。
Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung des Java-Servlet-Grafikcodes zum Funktionsprinzip der Sitzung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!