Com.sun.faces.numberOfViewsInSession vs com.sun.faces.numberOfLogicalViews

Mojarra Реализация JSF 2 имеет следующие параметры контекста:

  • com.sun.faces.numberOfViewsInSession (по умолчанию - 15)
  • com.sun.faces.numberOfLogicalViews (по умолчанию 15)

В чем разница между ними? В документации не говорится об этом. У моего приложения были проблемы с ViewExpiredException для некоторых страниц, но после того, как мы натолкнули эти настройки на (намного большее) значение, у нас остались проблемы.

Мое приложение - это финансовое, тяжелое приложение с поддержкой ajax (на некоторых экранах есть 50+ входов, с возможностью добавления большего количества данных/входов через AJAX).

что может быть причиной такого поведения? Я понимаю, что первый параметр определяет количество "страниц", которые хранятся в сеансе, что может быть полезно для кнопки "Назад", но мои варианты использования, которые запускают ViewExpiredException, не используют кнопку "Назад". На что ссылается второй параметр? Если я останусь на том же экране, но продолжаю добавлять много данных через AJAX, это вызывает необходимость большего количества логических просмотров для страницы?

ОТВЕТЫ

Ответ 1

Во-первых, реализация Mojarra непреднамеренно меняла смысл этих параметров контекста. Поэтому, если у вас создается впечатление, что описание в точности совпадает с тем, что подразумевает буквальное значение параметра контекста, тогда это действительно так.

com.sun.faces.numberOfLogicalViews

Это основной запрос GET. Каждый запрос GET создает новое представление в сеансе.

Чтобы поэкспериментировать с ним, установите значение 3, запустите новый сеанс браузера и откройте 4 разных вкладки браузера (независимо от URL-адреса, могут быть одинаковыми, могут быть разными) в последовательности, а затем вернуться к первому и отправьте форму там. Вы получите ViewExpiredException, потому что это представление было вытолкнуто из карты LRU (Наименее недавно использованная) для просмотров в сеансе. Это не произойдет, если вы открыли max 3 вкладки.

При значении по умолчанию 15, это редкая проблема в реальном мире. Если ваш webapp действительно предназначен для использования таким образом (например, социальный/общедоступный сайт, который приглашает к открытию на нескольких вкладках, таких как дискуссионный форум или Q & A), тогда вы можете рассмотреть возможность использования экономии на стороне клиента вместо увеличения значение по умолчанию. С сохранением состояния стороны клиента вы никогда не столкнетесь с этим исключением. Альтернативой было бы использовать OmniFaces <o:enableRestorableView> в сочетании с областью запроса bean и параметрами запроса или с охватом вида bean, который проверяет в (пост), если его собственное состояние необходимо восстановить. Опять другая альтернатива - перейти stateless с <f:view transient="true">, таким образом, представления больше не сохраняются, но вы больше не можете использовать область видимости beans.

эквивалент MyFaces org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION, который по умолчанию равен 20.

com.sun.faces.numberOfViewsInSession

Это в основном синхронный (не-ajax!) запрос POST. Каждый синхронный запрос POST создает новый логический вид. Все они хранятся на основе физического вида, такого как Map<PhysicalView, Map<LogicalView, ViewState>>. Таким образом, при максимальных 15 физических представлениях и максимальных 15 логических представлениях теоретически вы можете иметь 15 * 15 = 225 просмотров в сеансе.

Чтобы поэкспериментировать с ним, установите для него значение 3, откройте представление с синхронной формой, отправьте его 4 раза, а затем четыре раза нажмите кнопку назад, а затем снова отправьте форму. Вы получите ViewExpiredException, потому что это представление было вытолкнуто из карты LRU (Наименее недавно использованная) для логических представлений. Этого не произойдет, если вы вернетесь максимум 3 раза, а затем повторно отправьте его.

Обратите внимание, что ajax предоставляет повторное использование одного и того же логического представления (вы можете подтвердить его, увидев точно такое же значение javax.faces.ViewState, которое возвращается в postbacks ajax). В любом случае, поддержка кнопок в браузере отсутствует. Кнопка "Назад в браузере" возвращает вас к предыдущему синхронному запросу, поэтому не имеет смысла хранить все эти ajax-обратные передачи как логические представления в сеансе.

При значении по умолчанию 15 и текущей тенденции только для форм ajax и отключенного кэша на динамических страницах это очень редкая проблема в реальном мире. Правильно оформленные формы не должны приглашать на нажатие кнопки назад. Вместо этого они должны успешно отправить перенаправление на целевое представление, а при ошибке просто повторно отобразить ту же форму с ошибками проверки. См. Также подсказки Как перемещаться в JSF? Как сделать URL-адрес текущей страницы (а не предыдущей). Кроме того, кеш-память более чем часто отключается на динамических страницах, поэтому кнопка "Назад" в основном даст вам новый вид назад. См. Также Избегайте возврата на веб-приложение JSF. Если это также относится к вашему приложению, тогда вы можете безопасно установить значение 1.

Первоначально MyFaces не имел эквивалента для этого и считал это как физическое представление в сеансе. В версии 2.0.6 была введена org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION с аналогичной целью, но с другой реализацией и по умолчанию отключена.

См. также:

Ответ 2

Просто нашел это в Интернете: http://oss.org.cn/ossdocs/java/ee/javaeetutorial5/doc/JSFConfigure11.html

Это может быть полезно:

Логические представления - это представления верхнего уровня. Например, если у вас есть страница с несколькими кадрами, каждый кадр является логическим видом. Если у вас есть простое приложение, то по умолчанию 15 просмотров или 15 логических представлений могут быть слишком большими. В этом случае вы должны рассмотреть возможность уменьшения допустимого количества просмотров и логических представлений для сохранения памяти. И наоборот, для более сложного приложения может потребоваться сохранить более 15 просмотров или логических просмотров в сеансе.