Зачем устанавливать директиву JSP page session = "false"?
Мне было интересно, когда вы захотите установить следующую директиву страницы в JSP:
<%@ page session="false" %>
Я знаю, что это предотвращает создание объекта сеанса, но когда вам нужно это сделать? Считается ли это лучшей практикой, когда JSP не требуется доступ к неявному сеансу?
ПРИМЕЧАНИЕ. Причина, по которой я спрашиваю, заключается в том, что это было в этом учебном пособии по Spring MVC, и я предполагаю, что люди из источника источников знают свое дело - http://blog.springsource.com/2011/01/04/green-beans-getting-started-with-spring-mvc/
5 ответов
Одной из причин будет производительность и память. Если у вас есть страница, которая не требует участия в сеансе (например, about.jsp или же faq.jsp) тогда поведение по умолчанию, включающее каждый JSP в сеанс, будет накладывать накладные расходы на создание нового объекта сеанса (если он еще не существует) и увеличит использование памяти, так как все больше объектов находится в куче.
Этот эффект будет сильно преувеличен в случае, если на одной странице будет наблюдаться высокий трафик от многих уникальных пользователей в сочетании с высоким показателем отказов, т.е. они не продолжают просматривать сайт, а покидают сайт сразу после просмотра одной страницы - контейнер создаст новую Сеансовый объект на пользователя, который никогда не будет использоваться снова и, в конечном счете, будет собирать мусор после истечения времени ожидания - добавляются дополнительные затраты на создание объектов, использование памяти и сборку мусора, не давая вам никакой реальной ценности.
Этот параметр также является мерой безопасности, поскольку он также предотвращает потенциальную DoS- атаку. Подумайте о простом скрипте, который итеративно генерирует JSP: он сгенерирует много сессий за несколько секунд.
У меня на самом деле есть реальный сценарий в моем приложении для его использования. У нас есть Squid, выступающий в качестве обратного прокси-сервера перед нашим приложением. Сервер squid настроен на опрос всех экземпляров tomcat, на которых размещено наше приложение, чтобы убедиться, что серверы работают и, если они не работают, Squid переключится на использование другого сервера в нашем кластере.
Фактический опрос нашего приложения от Squid настроен на опрос определенной страницы в приложении. Поскольку опрос Squid на самом деле не является браузером, он не может содержать сеанс, а это означает, что каждый опрос на странице сервера должен был создать сеанс tomcat, на который Squid не может ссылаться. Мы добавляем <%@ page session="false" %> директива, чтобы сессия не создавалась при каждом опросе. Если бы мы не использовали эту директиву, у нас были бы тысячи сессий, созданных за 4 часа без всякой причины.
Еще один вариант использования, где на самом деле требуется добавить эту директиву, - это использование Apache Shiro's. noSessionCreation фильтр в .ini файл конфигурации, например, потому что ваша схема аутентификации не имеет состояния. Если вам этого не хватает, вы столкнетесь с org.apache.shiro.subject.support.DisabledSessionException,
Столкнулся с другим вариантом использования в моем производственном приложении, подумал, что я поделюсь им здесь, если это кому-нибудь поможет.
У нас есть приложение веб-интерфейса, которое защищает большинство ресурсов через сеанс. Однако некоторые ресурсы защищены частью веб-уровня, который находится перед нашим приложением в нашем производственном развертывании. Следовательно, что касается приложения, эти ресурсы полностью незащищены. Некоторые из этих "незащищенных" ресурсов являются JSP.
В случае, когда пользователь устанавливает сеанс на одном из наших защищенных ресурсов, а затем делает XHR-вызов из браузера на один из "незащищенных" ресурсов, мы столкнулись с проблемой, когда контейнер утверждает, что анонимный пользователь пытается получить доступ сеанс пользователя foo, тем самым останавливая выполнение. Конфигурирование "незащищенного" JSP, чтобы он не использовал сессии, помогло нам решить эту проблему.