Использование Stateful Session Bean для отслеживания сеанса пользователя

Question

это мой первый вопрос здесь, и я надеюсь, что я делаю это правильно.

Мне нужно поработать над проектом Java EE, поэтому, прежде чем начать, я пытаюсь сделать что-то простое и посмотреть,если я могу это сделать.

Я застрял с Stateful Session Beans .

Вот вопрос: Как я могу использовать SFSB дляотслеживать сеанс пользователя?Все примеры, которые я видел, закончились «помещением» SFSB в атрибут HttpSession .Но я не понимаю почему!Я имею в виду, если bean-компонент STATEFUL, почему я должен использовать HttpSession , чтобы сохранить его?

Разве это не задача EJB-контейнера для возврата правильного SFSB клиенту?

Я пробовал с помощью простого счетчика.Без использования сеанса два разных браузера имеют один и тот же компонент счетчика (нажатие на «приращение» изменило значение для них обоих).Используя сессию, у меня есть два разных значения, каждое для каждого браузера (щелкнув «приращение» в Firefox, добавив одно только к бину Firefox).

Но мой учитель сказал, что SFSB сохраняет«диалоговое состояние с клиентом», так почему оно не работает без использования HttpSession ?

Если я правильно понял, не используется HttpSession с SFSB то же самое, что и с SLSB вместо?

Я надеюсь, что мои вопросы ясны и что мой английский не настолько плохой!

РЕДАКТИРОВАТЬ: я работаю в системе входа в систему.Все идет хорошо, и после завершения входа в систему я перехожу на страницу профиля, на которой отображаются данные пользователя.Но при перезагрузке страницы мои данные исчезают!Я попытался добавить HttpSession при входе в систему, но при таком способе данные остаются даже после выхода из системы!

Answer 1

Stateful Session Bean (SFSB) необходимо комбинировать с HTTP-сессией в веб-среде, поскольку это чистый бизнес-бин, который сам ничего не знает о веб-слое.

Традиционно EJB-компоненты даже обязательно жили внутри своего собственного модуля (EJB-модуля), который даже не мог получить доступ к веб-артефактам, если бы захотел. Это аспект многоуровневых систем. См. Упаковка EJB в JavaEE 6 WAR против EAR для получения дополнительной информации об этом.

Первоначальными клиентами для Stateful Session Beans были, в частности, настольные приложения Swing, которые связывались с удаленным EJB-сервером по двоичному протоколу. Приложение Swing получит соединение с удаленным компонентом сеанса с сохранением состояния через объект прокси / заглушки. В этот прокси встроен некоторый идентификатор, который сервер может связать с определенной SFSB. Удерживая этот прокси-объект, клиент Swing может совершать к нему повторные вызовы, и они будут идти к одному и тому же экземпляру компонента. Таким образом, это создаст сеанс между клиентом и сервером.

В случае веб-приложения, когда браузер отправляет начальный запрос веб-приложению Java EE, он получает JSESSIONID, который сервер может связать с конкретным экземпляром HTTPSession. Удерживая этот JSESSIONID, браузер может предоставлять его каждому последующему запросу, и это активирует ту же самую HTTP-сессию на стороне сервера.

Итак, эти понятия очень похожи, но они не отображаются автоматически друг на друга.

Браузер получает только JSESSIONID и не знает ни о каком идентификаторе SFSB. В отличие от приложения Swing, браузер взаимодействует с веб-страницами, а не напрямую с Java-бинами.

Для отображения запроса клиента на конкретный сеансный компонент с состоянием, EJB-контейнер заботится только об идентификаторе, предоставленном через прокси-сервер SFSB. Он не может видеть, произошел ли вызов из кода в веб-модуле, и не может / не должен иметь доступ к любому HTTP-контексту.

Веб-слой, являющийся клиентским кодом, который обращается к SFSB, должен «держаться» за конкретную ссылку на прокси. Удерживание чего-либо в веб-слое обычно означает сохранение его в сеансе HTTP.

Однако существует технология моста, называемая CDI, которая может выполнять это автоматическое соединение. Если вы аннотируете свою SFSB с помощью CDI @SessionScoped и получаете ссылку на SFSB через CDI (например, с использованием @Inject), вам не нужно вручную помещать свою SFSB в сеанс http. Однако за кулисами CDI все равно будет делать это.

Answer 2

Вам нужно определить бин с помощью @SessionScoped вместо @RequestScoped (если вы ищете эквивалентное решение HttpSession)

что-то вроде

@SessionScoped
public class SessionInfo implements Serializable{
   private String name;
   public String getName() {
      return name;
   }
   public void setName(String name) {
      this.name = name;
   }
}

Посмотрите на следующее (объясненоподробно)

http://www.oracle.com/technetwork/articles/java/cdi-javaee-bien-225152.html