Один EJB сеанса без сохранения состояния для служебных функций?

Question

У меня есть некоторые служебные функции, которые могут быть вызваны из нескольких EJB сеансов без сохранения состояния. Эти служебные функции должны быть в новой транзакции (RequiresNew).

Имеет ли смысл создавать один EJB сеанса без сохранения состояния для всех этих функций? Utility?

Или я должен попытаться организовать их по функциональности, и в этом случае у меня будет несколько EJB-сеансов без сохранения состояния? Что повлияет на производительность системы, если у меня будет много таких EJB сеансов без сохранения состояния?

Некоторые примеры функций полезности:

• У меня есть таблица, где я храню сообщения с идентификатором. Создайте служебную функцию для получения сообщения для определенного идентификатора. Создайте служебную функцию для обновления сообщения для определенного идентификатора.

• У меня есть таблица, где я отслеживаю статусы некоторых процессов. Создайте служебную функцию для определения статуса определенного процесса. Создайте служебную функцию для обновления статуса определенного процесса.

и т.п.

Answer 1

С точки зрения производительности, для каждого EJB без сохранения состояния контейнер должен создавать экземпляр пула bean-компонента, содержащего экземпляры этого bean-компонента, и управлять им. (Как правило, это не большой размер, поскольку компоненты без состояния могут использоваться взаимозаменяемо. Я считаю, что по умолчанию в JBoss AS используется 20 экземпляров / пул). Если объединить их в один компонент, потребуется только один пул, но, вероятно, потребуется больше экземпляры, так как они должны обслуживать все типы вызовов. Таким образом, производительность не будет заметно затронута.

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

Я настоятельно рекомендую подумать о том, существуют ли значимые функциональные блоки, на которые можно разделить эти методы, даже если каждый из них довольно мал. Как предложили другие комментаторы, ваши два примера звучат как хорошие кандидаты на ProcessService и MessageService, Вы можете обнаружить, что когда вы смотрите на наборы функций, вы хотите добавить, что это не лучший способ разделить вещи, но это, вероятно, хорошая отправная точка. Если вы сейчас приложите усилия, чтобы определить, какие логические сервисы существуют в вашей системе, вы позже пожнете плоды в расширяемости и удобстве обслуживания.