Любое изменение в предпочтениях требует, чтобы пользователь начинал запрос сначала. Такой порядок может быть установлен как намеренно, так и ненамеренно, но он становится очевидным именно благодаря этому моделированию диалогового состояния.
Каждое состояние оказывает определенное влияние на данные. Иначе говоря, состояния явно идентифицируют данные, которые требуются для сеансового компонента при переходе к каждому новому состоянию. Например, когда сеансовый компонент находится в состоянии "Готов", он не имеет никакой информации о рейсах. Аналогично, если сеансовый компонент находится в состоянии "Выбраны оба сегмента", ясно, что он должен содержать полную и правильную информацию обо всех выбранных рейсах.
Пассивация экземпляра
Пассивация — %то полезная возможность, предоставляемая контейнером EJB специально для сеансовых компонентов с поддержкой состояний. Пассивация происходит, когда сервер EJB принимает решение выгрузить компонент из памяти, чтобы освободить память или другие системные ресурсы, а в этот момент EJB не находится в процессе транзакции клиента. Позднее выгруженный EJB может быть активизирован снова, обычно при следующем взаимодействии с клиентом.
Как только компонент активизируется, клиент возвращается к тому же самому объекту сеанса. Это доступно только для того клиента, который первоначально создал данный объект сеанса. Такое ограничение необходимо для сохранения диалогового состояния, а также для защиты информации, которую клиент поместил в данный объект сеанса.
Для компонентов, не имеющих состояний, пассивация экземпляра как отдельное намеренное действие не нужна, поскольку контейнер EJB в любом случае выгружает компоненты этого типа из памяти. Когда клиент заканчивает работу с объектом сеанса, этот объект очищается и возвращается обратно в группу компонентов. В следующий раз этот или другой объект сеанса активизируется, как только у любого клиента возникает в нем потребность. Для клиента этот объект каждый раз выглядит новым. В группе компонентов объекты сеансов сохраняются в активном виде, и если серверу EJB требуется освободить какое-то количество системных ресурсов, он лишь удаляет из группы некоторые незанятые компоненты, т.е. уничтожает их. Таким образом, в этом случае пассивация по сути является уничтожением объекта. Это допустимо, так как объект не должен хранить диалоговое состояние.
Объединение компонентов в группу позволяет обслуживать намного больше клиентов, чем имеется сеансовых компонентов. Однако нельзя забывать об ограничениях, которые накладывает такой подход, особенно для длительных и более сложных Web-транзакций. Неприятно будет обнаружить, что время, затрачиваемое на повторные инициализации сеансовых компонентов без поддержки состояний, перевешивает все их предполагаемые преимущества.
Существует предельное время, в течение которого сеансовый компонент имеет право занимать ресурсы на сервере EJB, не выполняя никакой полезной работы. Это ограничение установлено для таких ситуаций, когда, например, клиент по какой-то причине оставил Web-страницу и забыл вернуться на нее, или в сети произошел сбой, или в объекте сеанса записана информация тележки для покупок, которую клиент заполнил больше чем заданное число дней назад. Для таких ситуаций контейнер EJB использует механизм удаления компонента.
Удаление возможно для сеансовых компонентов любого типа. Оно обычно происходит, когда либо сеансовый компонент находится в состоянии пассивации дольше, чем позволяет настройка времени ожидания EJB, либо сервер EJB крайне нуждается в ресурсах и должен уничтожить некоторые незанятые компоненты. В очень редких случаях удаление также случается при сбое или отказе сервера EJB, поэтому Web-разработчики должны учитывать такой сценарий при проектировании сеансовых компонентов.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.