Если у меня есть @ManagedBean, что @SessionScoped, зачем мне использовать @Stateful EJB? Раньше я использовал его для покупок и поддерживал разговорное состояние, но поскольку управляемый bean будет храниться во время сеанса пользователя, я могу сохранить его там, а затем вызвать SLSB для логики бизнеса. Это верно? Если это так, то выдержки из состояния ожидания будут оставлены для более конкретных приложений, например, когда вам нужны транзакции и т.д.?
Sessioncoped managed bean vs stateful ejb
Ответ 1
Очень часто сеанс без состояния beans может использоваться для решения многих бизнес-задач.
Stateful не обязательно означает, что только удаленный сервер сохраняет состояние, хотя это, безусловно, один из вариантов. Удаленный клиент Swing может сначала отправить кучу данных в сеанс с состоянием bean, удерживать на заглушке, а затем отправлять некоторые команды, которые работают с этими данными. Это избавляет клиента от необходимости отправлять одинаковые (большие объемы) данные каждый раз.
В удаленном варианте использования он действительно несколько отражает использование сеанса HTTP, когда используются веб-клиенты (браузеры). Основное различие заключается в том, что сеанс на bean здесь, а при сеансе HTTP сеанс - это область, разделяемая многими beans. Поскольку сеанс HTTP основан на куки файлах, а куки файлы являются глобальными для домена для всего браузера, сеанс HTTP не может напрямую поддерживать несколько сеансов от одного и того же клиента (например, для каждой вкладки или для каждого окна). Это тривиально с сеансом состояния beans.
Однако...
Удаленные клиенты Swing, разговаривающие с удаленными EJB, не так уж часто встречаются.
В контексте, который вы описали в своем вопросе, вы обычно используете локальные EJB, и вы будете хранить большинство состояний в сеансе HTTP (будьте осторожны с совместным использованием!), и в наши дни в области видимости или области разговора.
Итак, наконец, когда использовать сеанс с состоянием beans в этом сценарии?
Одним из важных вариантов использования является extended persistence context в JPA. Обычно с диспетчером сущности транзакции, когда объект пересекает границу транзакции вызова метода EJB, он будет отсоединен. Если вы хотите (оптимистично) заблокировать сущность между пользовательскими взаимодействиями, это нежелательно. Вы потеряете блокировку.
С расширенным контекстом постоянства объект остается прикрепленным и блокировки действительны при возврате из сеанса сеанса с состоянием bean. Это очень полезно для функций предварительного просмотра, чтобы гарантировать, что никто другой не внес каких-либо изменений в объект, когда вы будете в порядке после предварительного просмотра. Или действительно для корзины покупок, где вы хотите заверить, что в течение некоторого времени предмет не может быть продан кому-либо еще в корзине.