2014-01-20 5 views
3

Из того, что я понимаю, ViewScoped бобы только разрушаются, когда один из следующих имеют место:Памятные последствия OmniFaces ViewScoped bean?

1) JSF отправляет запрос POST на другую страницу с чем-то вроде <h:commandLink...>

2) Число открытых фасолью превышает максимальное значение порога (по умолчанию 15)

3) сеанс пользователя истекает

Вот моя путаница:

ли # 1 означает, что если пользователь переходит от страницы с запросом GET, компонент останется открытым, даже если в конечном итоге JSF POST происходит на той же вкладке браузера на другой странице? Или все активные экземпляры @ViewScoped для этой вкладки браузера будут уничтожены после отправки отправления JSF независимо от того, на какой странице он включен?

Имеет ли №2, что пользователь может иметь 15 экземпляров боба, активных для каждого класса @ViewScoped? Или это 15 экземпляров bean независимо от класса, то есть я мог бы иметь 5 экземпляров Class1, 5 экземпляров Class2 и 5 экземпляров Class3, а новый компонент уничтожил бы самый старый активный компонент?

Для # 3, если для STATE_SAVING_METHOD установлено значение «клиент», будут ли какие-либо последствия уничтожены в объектах ViewScoped? Из того, что я помню, должен быть способ вручную управлять истечением сеанса, если STATE_SAVING_METHOD установлен для клиента.

Наконец, есть ли способ управлять активными компонентами ViewScoped, чтобы они могли быть уничтожены, когда пользователь нажимает «logout», например?

+2

Это будет длинная история, но в двух словах она не отличается от того, как работает JSF '@ ViewScoped'. – BalusC

+0

Для вашего последнего вопроса об управлении объектами '@ ViewScoped', я не вижу никакой причины для выполнения такой операции, если удаление сеанса гарантирует, что они будут удалены. –

+0

Я предполагаю, что последний вопрос есть в случае, если бобы не будут уничтожены при истечении срока действия сеанса, когда STATE_SAVING_METHOD настроен на клиента. Моя основная проблема заключается в том, что я храню слишком много информации в компонентах ViewScoped (таких как данные таблицы), которые не уничтожаются. Я хочу быть уверенным, что я правильно использую эту область. Кажется, что ViewScoped может быть просто предназначен для страниц с формами, которые уничтожаются с помощью кнопки отправки, но это также удобно для кэширования рассчитанных данных, если проблемы памяти не возникают из-за использования. –

ответ

1

Я понял ответы на них, добавив метод @PreDestroy для каждого компонента @ViewScoped и выполнив регистрацию, когда он будет уничтожен. Для других, которым может быть интересно:

Для # 1, bean не уничтожается, если вы переходите от страницы с запросом GET, но затем отправляете запрос на почту позже. Этот бит останется в памяти до тех пор, пока не будет достигнута настройка «максимальных активных областей видимости», и это приведет к тому, что очередь будет уничтожена, или сеанс недействителен.

Для № 2 класс не имеет значения. У вас может быть 5 экземпляров Class1, 5 экземпляров Class2 и 5 экземпляров Class3, а новый экземпляр bean ViewScoped уничтожит самый старый компонент, если ваш порог равен 15.

Для # 3 это похоже на фасоль будут уничтожены после того, как сессия будет признана недействительной, даже если для STATE_SAVING_METHOD установлен клиент.

+0

Спасибо за интересный вопрос и анализ. Вы замечаете, что не всегда различают «уничтоженные» в смысле вызываемых методов @ @ PreDestroy и способность мусора собирать сами виды. Я задал соответствующий вопрос здесь http://stackoverflow.com/questions/40569971/jsf-mojarra-vs-omnifaces-viewscoped-predestroy-called-but-bean-cant-be-gar и предоставил через GitHub тест веб-приложение для простого сравнения ссылок '@ PreDestroy' и кучи (сборка мусора) для разных типов bean-типов @ @ ViewScoped: https://github.com/webelcomau/JSFviewScopedNav –

 Смежные вопросы

  • Нет связанных вопросов^_^