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

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

Выдержка из учебника солнца ниже

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

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

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

Может кто-нибудь, пожалуйста, предоставьте некоторые детали?

благодарю вас!

Источник

6 ответов

Решение

Честно говоря, трудно найти какой-либо разумный вариант использования 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.

Источник

Используя 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-потоков. (синхронизированные, изменчивые, одновременные коллекции и т. д.)

Источник

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

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

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

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

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

Источник

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

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

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

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

Источник

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

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

Источник

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

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

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

Источник
Другие вопросы по тегам