Jag lade inte så mycket märke till det när jag pluggade tidigare, men idag gick jag tillbaka och studerade noggrant sessionens livscykel.
Sessioner lagras på serversidan, och generellt för att förhindra att de hamnar i serverns minne (för höghastighetsåtkomst), skapar Sessinon första gången användaren använder servern.Observera att endast åtkomst till JSP, Servlet och andra program skapar en session, och endast tillgång till statiska resurser som HTML och IMAGE skapar inte en session.
När går en session ut?
1. Servern rensar sessionen från serverminnet som varit inaktivt under lång tid, och sessionen blir ogiltig. Standardtiden för en session i Tomcat är 20 minuter.
2. Kalla på ogiltigförklaringsmetoden för sessionen.
Sessionskrav för webbläsare:
Även om sessionen lagras på servern och är transparent för klienten, kräver dess normala funktion ändå stöd från klientens webbläsare. Detta beror på att Session behöver använda cookies som identifierare. HTTP-protokollet är tillståndslöst, och sessionen kan inte bedömas av HTTP-anslutningen för att avgöra om det är samma kund, så servern skickar en cookie kallad JSESSIONID till klientwebbläsaren, som har värdet av sessionens id (det vill säga returvärdet av HttpSession.getId()). Session använder cookien för att identifiera om det är samma användare.
Denna cookie genereras automatiskt av servern, och dess maxAge-attribut är vanligtvis -1, vilket betyder att den endast är giltig i den aktuella webbläsaren, delas inte mellan webbläsarfönster, och kommer inte att vara giltig när webbläsaren är stängd. Därför, när två webbläsarfönster på samma maskin får tillgång till servern, genereras två olika sessioner. Förutom nya fönster som öppnas via länkar, skript etc. inom webbläsarfönstret (dvs. inte fönster som öppnas genom dubbelklick på skrivbordsikoner osv.). Dessa barnfönster delar föräldrafönstrets cookie och därmed en session.
Notera: Nya sessioner genereras i nyöppnade webbläsarfönster, förutom för underfönster. Barnfönstret delar sessionen med föräldrafönstret. Till exempel, när du högerklickar på en länk och väljer "Öppna i nytt fönster" i genvägsmenyn som dyker upp, kan barnfönstret komma åt föräldrafönstrets session.
Vad händer om klientwebbläsaren inaktiverar cookies eller inte stödjer cookies? Till exempel stöder den stora majoriteten av mobila webbläsare inte cookies. Java Web erbjuder en annan lösning: omskrivning av URL-adressen.
Omskrivning av URL-adresser är en lösning för klienter som inte stödjer cookies. Principen för omskrivning av URL-adresser är att skriva om användarens sessions id-information till URL-adressen. Servern kan tolka den omskrivna URL:en för att få sessions-id. På så sätt kan, även om klienten inte stödjer cookies, användas för att registrera användarens tillstånd. Klassen HttpServletResponse tillhandahåller encodeURL (sträng-url) för att implementera omskrivning av URL-adressen, vilket automatiskt avgör om klienten stöder cookies. Om klienten stödjer cookies kommer URL:en att matas ut som den är. Om klienten inte stödjer cookies skrivs användarsessionens id om till URL:en.
Observera: TOMCAT avgör om en klientwebbläsare stöder cookies baserat på om en cookie ingår i förfrågan. Även om klienten kan stödja cookies, eftersom inga cookies bärs på den första förfrågan (eftersom det inte finns några cookies som kan), kommer den omskrivna URL-adressen ändå att ha jsessionid i adressen. Servern har redan skrivit en cookie i webbläsaren vid andra besöket, så den omskrivna URL-adressen kommer inte att ha jsessionid i adressen.
|
Publicerad på 2015-04-19 19:44:59
|
|
|
Publicerad på 2017-03-18 16:52:21