Почему сеанс без состояния beans?

Ответ 1

Честно говоря, трудно найти разумный вариант использования 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 объединяются во избежание проблем с потоками при изменении состояния (?!?). Лично Я предпочитаю услуги singleton (Spring -like), и у меня никогда не было идеи SLSB. И да, я знаю одиночные EJB в EJB 3.1.

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

См. также:

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

Ответ 5

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

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

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

Ответ 6

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

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