Статические и инстансные члены в EJB без гражданства

1

У меня есть сеанс без состояния bean, которому нужен доступ к классу factory. Лучше ли объявлять этот класс factory как статический или экземплярный член в SLSB? Правильно ли я говорю, что, поскольку SLSB повторно используются, только один экземпляр factory будет создан за bean (при переходе с параметром члена экземпляра), в отличие от одного экземпляра для запроса?

Теги:
static
ejb
stateless

3 ответа

1
Лучший ответ

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

"Естественным" способом для SLSB является независимость каждого экземпляра, отсутствие статики, отсутствие синхронизации между экземплярами. Следовательно, если возможно, у меня будет экземпляр factory для экземпляра SLSB.

1

Не предполагайте, что экземпляр SLB не будет создан для каждого запроса. Контейнер находится в пределах своих прав на создание каждого запроса; В равной степени также разрешено иметь только один экземпляр (я думаю). В более общем плане контейнер будет содержать пул из них.

Если создание и/или инициализация вашего SLSB относительно дорого, вы должны выяснить, что именно будет делать ваш контейнер, и, если возможно, настроить его явно на то, что вы хотите.

Предполагая, что вы это сделали, тогда не должно быть никаких проблем с сохранением поля экземпляра в классе SLSB.

  • 0
    Интересно. Я могу представить сценарии, в которых контейнер мог бы решить реагировать на стресс, эффективно имея нулевой размер пула, и я могу себе представить, чтобы не настраивать пул. Я также вижу, что последняя из спецификаций позволит контейнеру создавать новый экземпляр для каждого запроса, но действительно ли это встречается в полезных средах производственного качества?
  • 0
    Я сомневаюсь в этом, но спецификации действительно разрешает это, и поэтому код не следует считать , в противном случае, если вы явно не ограничивают контейнер конфигурации.
0

Переменные экземпляра не воссоздаются, если SLSB повторно используется из пула. Жизненный цикл SLSB довольно прост: создайте экземпляр, используйте его n раз, чтобы посещать n запросов, и, в конце концов, выбросите его. Все эти действия выполняются контейнером. Таким образом, в процессе создания bean (контролируемого нами) мы можем инициализировать эти переменные экземпляра. Но никогда не изменяйте содержимое этих переменных после их инициализации, чтобы избежать побочных эффектов.

Вы можете использовать статические экземпляры, если хотите, но помните, что вы должны вручную обрабатывать проблемы синхронизации; и, кроме того, вы ограничены локальным factory.

Очень элегантное решение предоставляется EJB 3.1 с помощью EJB @Singleton.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню