J2EE: Синглтон против сохранения событий

Question

Когда следует хранить объект (то есть файл свойств всего приложения) в сеансе, в отличие от создания синглтона для его сохранения? Когда следует использовать каждый из этих подходов?

Примечание: Я работаю в кластерной среде, если это имеет какое-либо значение.

Answer 1

Если предполагается, что он распространяется на все приложение, вы должны хранить его не в области сеанса, а в области приложения.Сохраняя в области видимости сеанса, вы излишне дублируете одни и те же данные для каждого посетителя.Синглтон также вообще не нужен, просто создайте экземпляр один раз во время запуска сервера с помощью ServletContextListener и сохраните его в области приложения, используя ServletContext#setAttribute().

Answer 2

Примечание: я работаю в кластерной среде, если это что-то меняет.

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

Более того ...

Все профили Java EE имеют набор общих функций, таких какименование и внедрение ресурсов, правила упаковки, требования безопасности и т. д. Это гарантирует степень единообразия для всех продуктов и косвенных приложений, которые подпадают под зонтик «платформы Java EE».Это также гарантирует, что разработчики, знакомые с определенным профилем или с полной платформой, могут легко переходить к другим профилям, избегая чрезмерного разделения навыков и опыта.

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

Answer 3

+ 1 к BalusC, но я подозреваю, что это была просто опечатка с вашей стороны.

Что касается синглетонов, это зависит от того, что вы подразумеваете под синглтоном.Если у вас есть EJB с аннотацией @Singleton, то это нормально (другие поставщики внедрения зависимостей также могут поддерживать этот шаблон).

Если вы говорите о стандартном одноэлементном шаблоне, в котором экземпляр хранится в статической переменной, то это плохая идея.Как правило, вы должны избегать статических переменных в Java EE или контейнерах сервлетов, потому что загрузка классов может быть немного хитрой - вы можете получить несколько копий, когда вы этого не ожидаете, или вы можете делиться одной копией между различными приложениями,или вы можете хранить содержимое в памяти при повторном развертывании приложения.Вы можете сделать исключение в тех случаях, когда переменная не предоставляется вне класса, и вам неважно, сколько у вас ее копий (например, объектов регистратора).