Когда использовать сессионный компонент с сохранением состояния вместо сеансового компонента без сохранения состояния?


83

Сессионный компонент с отслеживанием состояния определяется следующим образом:

Сессионные компоненты с отслеживанием состояния Состояние объекта состоит из значений его переменных экземпляра. В сессионном компоненте с отслеживанием состояния переменные экземпляра представляют состояние уникального сеанса клиент-компонент. Поскольку клиент взаимодействует («разговаривает») со своим bean-компонентом, это состояние часто называется диалоговым состоянием.

Сессионный компонент без сохранения состояния определяется следующим образом:

Сессионные компоненты без состояния Сессионный компонент без состояния не поддерживает состояние диалога с клиентом. Когда клиент вызывает методы bean-компонента без состояния, переменные экземпляра bean-компонента могут содержать состояние, специфичное для этого клиента, но только на время вызова. Когда метод завершен, состояние, зависящее от клиента, не должно сохраняться. Однако клиенты могут изменять состояние переменных экземпляра в объединенных bean-компонентах без состояния, и это состояние сохраняется до следующего вызова объединенного bean-компонента без состояния. За исключением времени вызова метода, все экземпляры bean-объекта без состояния эквивалентны, что позволяет контейнеру EJB назначать экземпляр любому клиенту. То есть состояние сеансового компонента без сохранения состояния должно применяться ко всем клиентам.

Преимущество использования сеансового компонента без сохранения состояния над сеансовым компонентом с сохранением состояния заключается в следующем:

Поскольку сессионные компоненты без сохранения состояния могут поддерживать несколько клиентов, они могут предложить лучшую масштабируемость для приложений, которым требуется большое количество клиентов. Как правило, приложению требуется меньше сеансовых компонентов без сохранения состояния, чем для поддержки того же количества клиентов.

Поэтому возникает вопрос, когда следует использовать сессионные компоненты с отслеживанием состояния? На мой наивный взгляд, следует придерживаться использования сессионного компонента без сохранения состояния, насколько это возможно.

В каких кандидатах следует использовать сессионный компонент с отслеживанием состояния? Есть хорошие примеры?

Сессионный компонент


Ответы:


151

Во-первых, вы должны понять, как bean-компоненты создаются и обрабатываются на сервере.

Для сессионных компонентов без сохранения состояния состояния сервер может поддерживать переменное количество экземпляров в пуле. Каждый раз, когда клиент запрашивает такой компонент без состояния (например, с помощью метода), для обслуживания этого запроса выбирается случайный экземпляр. Это означает, что если клиент выполняет два последующих запроса, возможно, что два разных экземпляра bean-компонента без сохранения состояния будут обслуживать запросы. Фактически, между двумя запросами нет диалогового состояния. Также, если клиент исчезает, bean-компонент без состояния не уничтожается и может обслуживать следующий запрос от другого клиента.

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

Когда использовать stateless или stateful?

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

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


16
« Если клиенты исчезают, bean тоже уничтожается ». Фактически, сессионные компоненты с сохранением состояния не уничтожаются автоматически, если явно не вызывается метод, украшенный @Remove( javax.ejb) (этот метод даже не нужно кодировать. Его можно просто оставить пустым / пустым, если он аннотирован @Remove). Если связанный клиент забыл уничтожить компонент сеанса с отслеживанием состояния, этот компонент будет оставаться висящим на сервере до тех пор, пока сам контейнер не решит удалить его, используя свою собственную политику. Я ошибаюсь?
Tiny

3
Конечно ты прав. Более подробную информацию о жизненном цикле bean можно найти здесь: docs.oracle.com/javaee/6/tutorial/doc/giplj.html
tobiasdenzler

48

Я думаю, что лучший пример использования сессионного bean-компонента с отслеживанием состояния - это корзина для покупок , где вы храните все продукты, которые пользователь хочет купить.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.