Преди това не обръщах много внимание, когато учех, но днес се върнах и внимателно изучих жизнения цикъл на сесията. Сесиите се съхраняват от страна на сървъра и обикновено, за да се предотврати тяхното попадане в паметта на сървъра (за високоскоростен достъп), Sessinon създава първия път, когато потребителят достъпва сървъра.Имайте предвид, че достъпът само до JSP, Servlet и други програми ще създаде сесия, а достъпът само до статични ресурси като HTML и IMAGE няма да създаде сесия.
Кога изтича една сесия?
1. Сървърът ще изчисти сесията от паметта на сървъра, която е била неактивна дълго време, и сесията ще бъде невалидна. Стандартното време за изтичане на сесия в Tomcat е 20 минути.
2. Извикай метода за анулиране на сесията.
Изисквания за сесии за браузъри:
Въпреки че сесията се съхранява на сървъра и е прозрачна за клиента, нормалната ѝ работа все пак изисква поддръжката на браузъра на клиента. Това е така, защото Session трябва да използва бисквитки като идентификатор. HTTP протоколът е без състояние и сесията не може да бъде оценена по HTTP връзката, за да се определи дали е един и същ клиент, затова сървърът изпраща бисквитка, наречена JSESSIONID, към клиентския браузър, която има стойността на id на сесията (т.е. връщаната стойност на HttpSession.getId()). Session използва бисквитката, за да идентифицира дали е същият потребител.
Тази бисквитка се генерира автоматично от сървъра, а атрибутът ѝ maxAge обикновено е -1, което означава, че е валидна само в текущия браузър, не се споделя между прозорците на браузъра и няма да бъде валидна, когато браузърът е затворен. Следователно, когато два браузърни прозореца на една и съща машина достъпят сървъра, се генерират две различни сесии. С изключение на нови прозорци, отворени чрез връзки, скриптове и т.н. в прозореца на браузъра (т.е. не прозорци, отварящи се с двойно кликване върху икони на десктоп браузъра и т.н.). Тези дъщерни прозорци споделят бисквитките на родителския прозорец и следователно сесията.
Забележка: Новите сесии се генерират в новоотворени прозорци на браузъра, с изключение на подпрозорците. Дъщерният прозорец споделя сесията на родителския прозорец. Например, когато кликнете с десен бутон върху линк и изберете "Отвори в нов прозорец" в менюто с бързи пътища, което се появява, дъщерният прозорец може да достъпи сесията на родителския прозорец.
Какво ако клиентският браузър деактивира бисквитки или не поддържа бисквитки? Например, огромното мнозинство от мобилните браузъри не поддържат бисквитки. Java Web предлага друго решение: пренаписване на URL адреси. Пренаписването на URL адреси е решение за клиенти, които не поддържат бисквитки. Принципът на пренаписването на URL адреса е да се пренапише ID информацията на сесията на потребителя на URL адреса. Сървърът може да анализира пренаписания URL, за да получи идентификатора на сесията. По този начин, дори ако клиентът не поддържа бисквитки, сесията може да се използва за записване на състоянието на потребителя. Класът HttpServletResponse предоставя encodeURL (String url) за реализиране на пренаписване на URL адреси, което автоматично определя дали клиентът поддържа бисквитки. Ако клиентът поддържа бисквитки, URL адресът ще бъде изведен както е. Ако клиентът не поддържа бисквитки, идентификаторът на потребителската сесия се презаписва в URL адреса.
Забележка: TOMCAT определя дали клиентският браузър поддържа бисквитки въз основа на това дали бисквитката е включена в заявката. Въпреки че клиентът може да поддържа бисквитки, тъй като при първата заявка няма бисквитки (тъй като няма бисквитки, които да могат), пренаписаният URL адрес все пак ще съдържа jsessionid в адреса. Сървърът вече е написал бисквитка в браузъра при второто посещение, така че пренаписаният URL адрес няма да има jsessionid в адреса.
|