У меня есть сеанс без состояния bean, которому нужен доступ к классу factory. Лучше ли объявлять этот класс factory как статический или экземплярный член в SLSB? Правильно ли я говорю, что, поскольку SLSB повторно используются, только один экземпляр factory будет создан за bean (при переходе с параметром члена экземпляра), в отличие от одного экземпляра для запроса?
экземпляры SLSB объединены и, следовательно, обслуживают потенциально много запросов в течение их жизненного цикла, так как вы говорите, что переменные экземпляра не воссоздаются для каждого запроса.
"Естественным" способом для SLSB является независимость каждого экземпляра, отсутствие статики, отсутствие синхронизации между экземплярами. Следовательно, если возможно, у меня будет экземпляр factory для экземпляра SLSB.
Не предполагайте, что экземпляр SLB не будет создан для каждого запроса. Контейнер находится в пределах своих прав на создание каждого запроса; В равной степени также разрешено иметь только один экземпляр (я думаю). В более общем плане контейнер будет содержать пул из них.
Если создание и/или инициализация вашего SLSB относительно дорого, вы должны выяснить, что именно будет делать ваш контейнер, и, если возможно, настроить его явно на то, что вы хотите.
Предполагая, что вы это сделали, тогда не должно быть никаких проблем с сохранением поля экземпляра в классе SLSB.
Переменные экземпляра не воссоздаются, если SLSB повторно используется из пула. Жизненный цикл SLSB довольно прост: создайте экземпляр, используйте его n раз, чтобы посещать n запросов, и, в конце концов, выбросите его. Все эти действия выполняются контейнером. Таким образом, в процессе создания bean (контролируемого нами) мы можем инициализировать эти переменные экземпляра. Но никогда не изменяйте содержимое этих переменных после их инициализации, чтобы избежать побочных эффектов.
Вы можете использовать статические экземпляры, если хотите, но помните, что вы должны вручную обрабатывать проблемы синхронизации; и, кроме того, вы ограничены локальным factory.
Очень элегантное решение предоставляется EJB 3.1 с помощью EJB @Singleton.