Последствия масштабируемости преобразования сессионных компонентов без сохранения состояния в POJO

Question

Представьте себе интенсивно используемый сервисный объект, который реализован как EJB 2.1 SLSB, и который сам по себе является поточно-ориентированным благодаря отсутствию состояния вообще. Все его открытые методы являются транзакционными (через CMT), наиболее просто требующими транзакции, но некоторые требуют новой транзакции.

Если я преобразую этот SLSB в подлинный одноэлементный POJO (например, с использованием инфраструктуры DI), как это повлияет на масштабируемость приложения? Когда сервис представлял собой SLSB, контейнер EJB управлял пулом экземпляров, из которых каждый клиент получал свою собственную копию, поэтому мне интересно, будет ли превращение его в одноэлементный POJO вызвать какой-то конфликт для этого единственного экземпляра.

FWIW, ни один из методов этой службы не является synchronized.

Разъяснение: моя мотивация для преобразования SLSB в POJO - это простота как жизненного цикла объекта (истинный синглтон по сравнению с управлением контейнером), так и самого кода (один интерфейс и один аннотированный POJO, по сравнению с тремя интерфейсами, одним классом бина, и куча XML в ejb-jar.xml).

Кроме того, FWIW, рассматриваемая служба является одним из компонентов совместно размещенного веб-приложения, работающего на JBoss 3.x.

Answer 1

Если POJO действительно не имеет состояния или не имеет диалогового состояния (т. Е. Состояние является неизменным), то это не ухудшит производительность и даже может немного улучшиться, поскольку вы действительно используете только один экземпляр из своей структуры DI, а не пул из контейнера. (Даже бассейн страдает от конкуренции при высокой нагрузке.)

Не требуется синхронизация для объекта, ориентированного на многопотоковое исполнение, такого как объект с отсутствующим или просто неизменным состоянием. Не будет никаких конфликтов - потоки могут свободно выполнять методы в POJO без синхронизации.

Используя только POJO, вы также можете реально увидеть, что происходит в вашем приложении, и можете быть уверены, что за кулисами не происходит скрытой "магии контейнера".

Answer 2

Ваш POJO кажется идеальным.

Так что нет, не будет споров, ваша масштабируемость будет идеальной.

• У вас нет дополнительных затрат.
• У вас даже меньше, потому что у вас есть один экземпляр вместо нескольких
• Ваша масштабируемость лучше, потому что вы никогда не достигнете предела своего пула (у вас его нет).