Почему сессионные компоненты без состояния?

Question

Я читал о сессионном компоненте без сохранения состояния и не мог понять, как его использовать.

Выдержка из учебника Sun ниже

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

Где используется сессионный компонент без сохранения состояния?какие приложения используют его?

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

Может кто-нибудь сообщить какие-нибудь подробности?

спасибо!

Answer 1

Используя EJB 3.0, по моему мнению, компоненты Stateless Session существуют для того, чтобы завершить ландшафт Enterprise Bean. Они действительно существуют для того, чтобы настроить Фасад для остальной части вашей бизнес-логики. Люди часто предполагают, что SLSB безопасны для потоков, но это, по меньшей мере, вводит в заблуждение.

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

Поскольку контексты EE (транзакции, ресурсы безопасности и т. Д.) Уже связаны с потоком, я не вижу необходимости в SLSB, скажем, в Spring Singletons. Они дополняют компоненты Statefull Session в приложении, предназначенном только для EJB.

По моему мнению, маршрут, который они выбирают с помощью SLSB, и новые настройки параллелизма блокировки для EJB 3.1 - это попытка сбить с толку программиста и заставить Mighty Container удовлетворить ваши потребности. Сделайте себе одолжение и прочитайте Java Concurrency in Practice и начните использовать синглтоны в сочетании со стандартными конструкциями параллелизма java-потоков. (синхронизированные, изменчивые, одновременные коллекции и т. д.)

Answer 2

Если честно, трудно найти какой-либо разумный вариант использования SLSB. Поскольку они не содержат никакого состояния (как следует из названия), они должны быть поточно-ориентированными. Даже если они объединены в контейнер.

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

@Stateless
public class Slsb {
  private int counter;

  public void increment() {
    ++counter;
  }

  public int getCounter() {
    return counter;
  }
}

на стороне клиента:

@Resource
private Slsb slsb;

public void clientMethod() {
  slsb.increment();
  slsb.increment();
  slsb.getCounter();  //???
}

Этот код (несмотря на его вульгарность) прекрасно подходит и не требует, например, AtomicInteger.

Какой результат вы ожидаете? На самом деле, любое неотрицательное значение возможно ... Любой вызов slsb может обслуживаться другим экземпляром Slsb, и в то же время ваш (ранее использовавшийся) экземпляр мог использоваться для обслуживания разных клиентов. Вывод: сохранение состояния в SLSB неверно, но по какой-то причине SLSB объединяются, чтобы избежать проблем с многопоточностью при изменении состояния (?!?). Лично Я предпочитаю синглтон-сервисы (Spring-like), и у меня никогда не было идеи SLSB. И да, я знаю об одноэлементных EJB в EJB 3.1.

Answer 3

Вопреки тому, что большинство ответов здесь позволяют верить, безгражданство не имеет ничего общего с безопасностью потоков самого класса. Это абсолютно не основная цель @Stateless. Сам разработчик по-прежнему несет ответственность за то, что класс, представляющий @Stateless EJB, не имеет объявленных переменных экземпляра (т.е. не имеет состояния). Контейнер не несет ответственности за эту часть. По сути, разработчик должен сказать: «Эй, контейнер, это класс бизнес-сервисов без состояния, я аннотирую его с помощью @Stateless, чтобы вы могли использовать его как EJB без сохранения состояния», и, следовательно, не наоборот или около того.

Если вы хотите указать состояние, тогда используйте @Stateful, который будет заново создаваться каждый раз, когда клиент его получает (поэтому, если клиент, например, является управляемым компонентом JSF с областью видимости, то EJB будет жить столько времени, сколько этот компонент или, если клиент является, например, управляемым компонентом CDI в рамках сеанса, то EJB будет жить так же долго, как этот компонент и т. д.). Или используйте @Singleton, который в основном ограничен областью применения и фактически заблокирован потоком.

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

Обратите внимание, что @Singleton не объединяется в пул и по умолчанию фактически блокируется потоком. Теперь вы должны понимать, что @Singleton по умолчанию абсолютно не быстрее, чем @Stateless, когда (ab) используется как "EJB без сохранения состояния". Смотрите также Учебник по Java EE 7 "Управление параллельным доступом в одноэлементном сессионном компоненте" .

Смотри также:

• Когда необходимо или удобно использовать Spring или EJB3 или все вместе?
• Компонент JSF в области запросов продолжает воссоздавать новые сессионные компоненты Stateful при каждом запросе?
• При использовании @EJB каждый управляемый компонент получает свой собственный экземпляр @EJB?
• EJB @ Asynchronous для извлечения вставленной в реальном времени строки в JSF, кажется, заблокирован потоком

Answer 4

Первые сеансовые компоненты без сохранения состояния (SLSB) представляют собой технологию на стороне сервера - вы не используете их, например, в свинг-коде.

Но они, например, используются как «Фасад» для многих клиентов, которые подключаются к центральным серверам. SLSB содержит бизнес-логику и может, например, вызов в базы данных.

Поскольку SLSB может быть объединен в пул, вам не нужен один SLSB для каждого клиента, а только один для каждого клиента одновременно. Когда SLSB не используется, он помещается обратно в пул и может использоваться для следующего клиента.

Поскольку SLSB «размещены» в контейнере, они являются поточно-ориентированными, и контейнер выполняет для вас большую работу: транзакции, безопасность, внедрение ресурсов и т. Д.

Answer 5

Объект без сохранения состояния позволит вам свободно связываться с клиентом и, таким образом, позволит вам легко масштабироваться.

Сессионные компоненты без сохранения состояния (SLB) - это компоненты сервера (EJB), которые используются для абстрагирования вашей бизнес-логики. Из-за этой самой природы отсутствия состояния вы можете легко развернуть ваши SLB в другом контейнере, который не работает поверх той же JVM. И согласно вашему требованию вы можете иметь один или несколько контейнеров, работающих с этими бобами.

Answer 6

С точки зрения технологии, не относящейся к EJB, Session Beans без состояния - это инфраструктурный код, который, очевидно, не содержит никакого состояния, но передает объекты, которые имеют это состояние.State может видеть ваши Stateful Session Beans или Domain POJO в других реализациях вне EJB.Как указано в приведенном выше комментарии, это точка входа или фасад вашего бизнес-уровня.

В веб-приложении java вы можете проектировать по слоям, таким как Контроллер, Класс обслуживания (SLSB или просто Java-взаимодействие).затем DAO или что-либо еще, чтобы вызвать базу данных / бэкэнд.

EJB, однако, выполняет некоторый автоматический подъем котельной пластины, такой как транзакции, безопасность и тому подобное.