Зачем объединять сессионные компоненты без сохранения состояния?

Question

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

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

Answer 1

Объединение делает несколько вещей.

Во-первых, при наличии одного компонента на экземпляр вы гарантированно безопасны для потоков (например, сервлеты не являются потокобезопасными).

Во-вторых, вы уменьшаете любое потенциальное время запуска, которое может иметь бин. В то время как сессионные компоненты являются «не имеющими состояния», они должны быть только не имеющими состояния в отношении клиента. Например, в EJB вы можете добавить несколько ресурсов сервера в Session Bean. Это состояние является частным для bean-компонента, но нет причины, по которой вы не можете удерживать его от вызова до вызова. Таким образом, объединяя компоненты в бины, вы сводите эти запросы к выполнению только при создании компонента.

В-третьих, вы можете использовать бобовый пул в качестве средства регулирования трафика. Если в пуле только 10 Бинов, вы получите только 10 одновременно работающих запросов, а остальные будут поставлены в очередь.

Answer 2

Транзакционность модели Java EE использует контекст потока для управления жизненным циклом транзакции.

Это упрощение существует, так что нет необходимости реализовывать какой-либо конкретный интерфейс для непосредственного взаимодействия с объектом UserTransaction; когда транзакция извлекается из InitialContext (или внедряется в сессионный компонент), она привязывается к локальной переменной потока для повторного использования (например, если метод в вашем компоненте сеанса без состояния вызывает другой компонент сеанса без состояния, который также использует внедренную транзакцию. )

Answer 3

Объединение повышает производительность.

Один экземпляр, обрабатывающий все запросы / потоки, может привести к большому количеству конфликтов и блокировок.

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

Контейнер может управлять размером пула на основе фактической активности.

Answer 4

Методы по своей природе БЕЗОПАСНЫ ДЛЯ РЕЗЬБЫ (включая статические). Зачем? Все просто, потому что каждая переменная внутри метода создается в стековой памяти, то есть каждая переменная, используемая внутри метода, создается за вызов (она не используется совместно). Однако параметры не являются частью стека.

Однако метод небезопасен, если он использует небезопасную переменную:

а) вызов статического поля или переменной. Однако это происходит в каждом отдельном случае.

б) вызов ресурса, которым он поделился. Например EntityManager.

c) передача небезопасного параметра.

Answer 5

Жизненный цикл сессионных компонентов Statelesss: состояние «Не существует», «Пассивное» и «MethodReady» («Пассивный» или «Неактивный»). Чтобы оптимизировать производительность, вместо того, чтобы обходить весь компонент от состояния готовности до создания, контейнер управляет компонентом между активным и пассивные состояния через обратные вызовы контейнера - ejbActivate () и ejbPassivate (), управляя пулом компонентов.

sreenut