it-roy-ru.com

Почему JSF сохраняет состояние компонентов пользовательского интерфейса на сервере?

  1. До какого момента времени JSF сохраняет состояние компонентов пользовательского интерфейса на стороне сервера и когда именно информация о состоянии компонента пользовательского интерфейса удаляется из памяти сервера? Как зарегистрированный пользователь в приложении просматривает страницы, будет ли состояние компонентов накапливаться на сервере?

  2. Я не понимаю в чем преимущество сохранения состояния компонентов пользовательского интерфейса на сервере!? Не достаточно ли непосредственно передать проверенные/преобразованные данные в управляемые bean-компоненты ? Могу ли я или я должен попытаться избежать этого?

  3. Разве это не потребляет слишком много памяти на стороне сервера, если есть тысячи одновременных пользовательских сессий? У меня есть приложение, где пользователи могут публиковать блоги на определенные темы. Эти блоги довольно большие по размеру. Когда будет отправлено сообщение назад или запрос на просмотр блогов, будут ли эти большие данные страницы сохранены как часть состояния компонентов? Это будет съедать слишком много памяти. Разве это не проблема?


Обновление 1:

Теперь больше нет необходимости сохранять состояние при использовании JSF. Высокоэффективная реализация Stateless JSF доступна для использования. Смотрите это блог & этот вопрос для соответствующих деталей и обсуждения. Кроме того, есть открытый выпуск для включения в спецификации JSF, опция для обеспечения режима без сохранения состояния для JSF. (П.С. Подумайте о том, чтобы проголосовать за вопросы это & это , если это полезная функция для вас.)


Обновление 2 (24-02-2013):

Хорошая новость в том, что Мохарра 2.1.19 вышла из режима без состояния !

Посмотреть здесь:

http://weblogs.Java.net/blog/mriem/archive/2013/02/08/jsf-going-stateless?force=255

http://Java.net/jira/browse/JAVASERVERFACES-2731

http://balusc.blogspot.de/2013/02/stateless-jsf.html

103
Rajat Gupta

Почему JSF необходимо сохранять состояние компонентов пользовательского интерфейса на стороне сервера?

Потому что HTTP не имеет состояния, а JSF - это состояние. Дерево компонентов JSF подвержено динамическим (программным) изменениям. JSF просто нужно знать точное состояние, каким оно было, когда форма отображалась конечному пользователю, чтобы он мог успешно обработать весь жизненный цикл JSF на основе информации, предоставленной исходным деревом компонентов JSF, когда форма была отправлена ​​обратно сервер. Дерево компонентов предоставляет информацию об именах параметров запроса, необходимых преобразователях/валидаторах, связанных свойствах управляемого бина и методах действий.


До какого момента времени JSF сохраняет состояние компонентов пользовательского интерфейса на стороне сервера и когда именно информация о состоянии компонента пользовательского интерфейса удаляется из памяти сервера?

Эти два вопроса, кажется, сводятся к одному и тому же. В любом случае, это зависит от реализации и также зависит от того, сохраняется ли состояние на сервере или клиенте. Немного приличная реализация удалит его, когда он истек или когда очередь заполнена. Например, Mojarra имеет ограничение по умолчанию в 15 логических представлений, когда сохранение состояния установлено на сеанс. Это настраивается с помощью следующего параметра контекста в web.xml:

<context-param>
    <param-name>com.Sun.faces.numberOfLogicalViews</param-name>
    <param-value>15</param-value>
</context-param>

См. Также Часто задаваемые вопросы по Mojarra другие параметры, относящиеся к Mojarra, и соответствующий ответ com.Sun.faces.numberOfViewsInSession vs com.Sun.faces.numberOfLogicalViews


Поскольку вошедший в систему пользователь просматривает страницы, будет ли на сервере накапливаться состояние компонентов?

Технически это зависит от реализации. Если вы говорите о переходе от страницы к странице (только запросы GET), то Мохарра не будет ничего сохранять в сессии. Однако если они являются запросами POST (формы с командными ссылками/кнопками), то Mojarra сохранит состояние каждой формы в сеансе до максимального предела. Это позволяет конечному пользователю открывать несколько форм на разных вкладках браузера в одном сеансе.

Или, когда сохранение состояния установлено на клиент, JSF ничего не будет хранить в сеансе. Вы можете сделать это с помощью следующего параметра контекста в web.xml:

<context-param>
    <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
    <param-value>client</param-value>
</context-param>

Затем он будет сериализован в зашифрованную строку в скрытом поле ввода с именем javax.faces.ViewState формы.


Я не понимаю, в чем преимущество сохранения состояния компонента пользовательского интерфейса на стороне сервера. Не достаточно ли напрямую передать проверенные/преобразованные данные управляемым компонентам? Могу ли я/я должен попытаться избежать этого?

Этого недостаточно для обеспечения целостности и надежности JSF. JSF - это динамическая структура с единой точкой входа контроля. Без управления состоянием можно было бы подделать/взломать HTTP-запросы определенным образом (например, манипулировать атрибутами disabled, readonly и rendered), чтобы JSF мог выполнять разные - и потенциально опасные - вещи. Это было бы даже склонно к атакам CSRF и фишингу.


И не будет ли это занимать слишком много памяти на стороне сервера, если есть тысячи одновременных пользовательских сессий? У меня есть приложение, где пользователи могут публиковать блоги на определенные темы. Эти блоги довольно большие по размеру. Когда появится обратная запись или запрос на просмотр блогов, большие блоги будут сохранены как часть состояния компонентов. Это будет занимать слишком много памяти. Разве это не проблема?

Память особенно дешевая. Просто дайте серверу приложений достаточно памяти. Или, если пропускная способность сети вам дешевле, просто переключите сохранение состояния на клиентскую сторону. Чтобы найти наилучшее совпадение, просто выполните стресс-тестирование и профилируйте свое веб-приложение с ожидаемым максимальным количеством одновременных пользователей, а затем предоставьте серверу приложений 125% ~ 150% от максимальной измеренной памяти.

Обратите внимание, что JSF 2.0 значительно улучшил управление состоянием. Можно сохранить частичное состояние (например, только <h:form> будет сохранен вместо всего материала от <html> до самого конца). Мохарра, например, делает это. Средняя форма с 10 полями ввода (каждое с меткой и сообщением) и 2 кнопками займет не более 1 КБ. При 15 сеансах просмотра это должно быть не более 15 КБ на сеанс. При ~ 1000 одновременных пользовательских сеансах это должно быть не более 15 МБ.

Ваша задача должна быть более сфокусированной на реальных объектах (управляемых bean-компонентах и ​​/ или даже объектах БД) в области сеанса или приложения. Я видел много кодов и проектов, которые излишне дублируют всю таблицу базы данных в памяти Java в духе bean-объекта с сессионной областью, где вместо фильтра SQL/группировки/упорядочения записей используется Java. При ~ 1000 записях это легко превысит 10 МБ за сеанс пользователя .

196
BalusC