Добавление к совету duffymo; Есть некоторые дополнительные соображения по использованию bean-компонентов сеанса с сохранением состояния по сравнению с использованием сеанса HTTP.
Сеанс HTTP в основном имеет структуру, подобную карте. Он напрямую доступен для всех потоков (запросов), которые являются частью сеанса. Это делает манипулирование несколькими предметами относительно небезопасным действием. Можно выполнить синхронизацию в самом сеансе, но это рискованная операция, которая может привести к полной блокировке всего приложения. Сеанс HTTP позволяет объявлять прослушиватели событий, которые запускаются при любых изменениях сеанса http.
Сессионный компонент с сохранением состояния, конечно, имеет структуру компонента. Он имеет своего рода функцию автоматической синхронизации, поскольку в бине одновременно может быть активен только поток. С помощью аннотаций вы можете объявить, если другие потоки ждут (и если да, то как долго), или немедленно выдать исключение в случае одновременного доступа.
Там, где обычно есть только один http-сеанс на пользователя, один пользователь может одновременно использовать несколько сессионных компонентов с состоянием. Особое преимущество сессионных компонентов с сохранением состояния заключается в том, что у них есть механизм пассивации своего состояния после некоторого времени ожидания, который может освободить память вашего сервера (разумеется, за счет дискового пространства). Сессионные компоненты с сохранением состояния не имеют напрямую таких слушателей событий, как сеанс http.
Я думаю, что изначально «сессионный» аспект сессионных компонентов с состоянием состоял в том, чтобы поддерживать сеанс с удаленными не веб-клиентами (Swing, другой AS и т. Д.). Это очень похоже на сеанс http, созданный для поддержки сеанса с удаленными веб-клиентами. Поскольку не-веб-клиент может запрашивать и поддерживать несколько прокси-серверов для сеансовых компонентов с сохранением состояния, веб-аналогия на самом деле больше похожа на недавно введенную conversation scope.
В случае, когда удаленные веб-клиенты общаются с сервером, где сервер внутренне общается с сессионным компонентом с состоянием, понятия сильно перекрывают . Удаленный веб-клиент знает только о сеансе http (через JSESSIONID) и ничего не говорит о сеансе сессионного компонента с состоянием. Таким образом, если сеанс http был потерян, вы, как правило, не сможете снова подключить удаленный клиент к определенному компоненту сеанса с сохранением состояния. Таким образом, в этом случае HTTP-сеанс всегда является ведущим, и вы можете также хранить элементы корзины покупок внутри одного (http) компонента в области сеанса.
Существует один конкретный случай, когда сессионные компоненты с сохранением состояния пригодятся для внутренней коммуникации, и это если вам нужны JPA extended persistence context. Это можно использовать, например, если блокировки между сущностями должны продолжаться между запросами (что, возможно, удобно для корзины покупок, если у вас ограниченный запас и вы не хотите сообщать пользователю сообщение «нет в наличии», как только он фактически выписывается).