Синглтон в Java App Server. Насколько это плохо?

Question

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

Чтобы мне было проще, я думаю сделать «черный ящик» синглтоном. По сути, любой, кто хочет получить доступ к логике внутри черного ящика, получит тот же экземпляр. Это позволит мне использовать компоненты, управляемые сообщениями, в качестве входных данных для черного ящика, а также JMS Publisher в качестве выходных данных для черного ящика.

Насколько это плохая идея? Любые советы?

Одна из основных проблем, с которыми я сталкиваюсь, заключается в том, что в коде «черного ящика» могут быть Темы, о которых я не знаю.

Есть ли в EJB такая вещь, как "объекты области приложения"?

Примечание: я использую Glassfish

Answer 1

Если вы используете простой сингелтон, вы столкнетесь с проблемами при входе в кластерную среду .

В таком сценарии у вас есть несколько загрузчиков классов на нескольких JVM, и ваш шаблон sinlgeton будет сломаться, так как у вас будет несколько экземпляров этого класса.

Единственное приемлемое использование синглтона на сервере приложений (возможно, в кластерной среде) - это когда синглтон полностью не имеет состояния и используется только для удобства доступа к глобальным данным / функциям.

Я предлагаю проверить решение вашего поставщика сервера приложений для этой проблемы. Большинство, если не все поставщики, предоставляют какое-то решение для ваших требований.

Специально для Glassfish, который, как вы говорите, используете, проверьте Поддержка Singleton EJB для Glassfish . Это может быть так же просто, как добавить одну аннотацию.

Answer 2

Я бы сказал, что создание синглтона - фактически единственная жизнеспособная идея. Предполагая, что код внутри этого «черного ящика» использует статические поля, абсолютно небезопасно создавать два экземпляра этого фасада. В противном случае результаты непредсказуемы.

Answer 3

Мне не хватает точки? Вы упомянули, что «код черного ящика» содержит состояние. Количество MDB может быть ограничено 1 экземпляром на пункт назначения, но без правильной конфигурации у вас будет несколько MDB. Все они работают с вашим единственным экземпляром «кода черного ящика». Мне кажется, что это не очень хорошая идея, потому что один бин переопределяет состояние «черного ящика», а другой бин создал несколько тиков раньше.

Answer 4

Это должно работать, но есть некоторые проблемы, с которыми вам, возможно, придется столкнуться.

Threading, как вы уже упоминали. MDB запускается в контейнере EJB, где вы не можете создавать свои собственные потоки, поэтому у вас есть потенциальная проблема там. Если у вас есть доступ к реальному коду (который звучит так же, как и у вас), вы можете захотеть провести некоторый рефакторинг, чтобы либо удалить потоки, либо использовать «одобренный» метод потоков. CommonJ TimerManager, вероятно, будет работать в указанном вами случае, поскольку он выполняет некоторую задачу с интервалом. Существуют реализации, доступные для большинства серверов приложений (включая WAS и Weblogic).

Загрузка классов - это зависит от вашей конфигурации. Если синглтон создается и управляется из MDB в пределах одного EAR, все будет в порядке. Отдельные EAR будут означать разные загрузчики классов и несколько ваших экземпляров Singleton. Не могу прокомментировать, будет ли это проблемой в вашем случае или нет без дополнительной информации.

Answer 5

Отнюдь не плохая идея, на самом деле она звучит для меня как потенциально довольно хорошая идея.

Просто с точки зрения разработки программы: если ваш черный ящик концептуально является «объектом» со свойствами и методами, которые над ними работают, то превратите его в объект, даже если будет создан только один из них .

Answer 6

Мне кажется, что артефакт, который лучше всего соответствует вашим требованиям, - это JBoss MBean. (Если вы думаете о JBoss в качестве кандидата).

Стандартный пример MBean

MBean-компоненты также могут быть развернуты как синглтоны в случае кластеризации JBoss.

Кластеризация с JBoss

Я надеюсь, что это полезно для вас.

Раф.

Answer 7

ИМХО, неплохо бы иметь EJB-контейнер для ваших нужд Singleton. В Java EE 6 размещение аннотации @Singleton в вашем сессионном компоненте дает вам именованный синглтон.

Answer 8

Почему бы не создать интерфейс отдыха для пустой коробки и позволить клиентам совершать http-вызовы?

Answer 9

В мире веб-сервера объект может быть ограничен запросом, сеансом или приложением. Возможно, вам нужен объект области приложения.

Поиск в документах "объекта области приложения" или "объекта времени жизни приложения".

Answer 10

Не используйте Singletons, где состояние может измениться.

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