Nano Hash - криптовалюты, майнинг, программирование

Java: MDB и SingletonBeanFactoryLocator Spring

В кодовой базе, которую я унаследовал, есть MDB, который вызывает SingletonBeanFactoryLocator().getIntance().useBean(), чтобы получить ссылку на фабрику в своем ejbCreate(), а затем получает конкретный bean-компонент из этой фабрики и сохраняет его как переменную экземпляра MDB. (Фабрика имеет тип 'ClassPathXmlApplicationContext').

Смущает следующее: после того, как этот bean-компонент получен, он вызывает 'release()' для этой фабричной ссылки в том же самом ejbCreate().

Теперь этот MDB объединен в пул с размером пула 'x', и я заметил, что bean-компоненты, определенные в context xml, создаются 'x' количество раз. Итак, я предполагаю, что каждый раз, когда выполняется 'ejbCreate()', он заново создает контекст и его компоненты.

Я проверил документ Spring для 'release() выше, в котором говорится:

In an EJB usage scenario this would normally be called from `ejbRemove()` and `ejbPassivate()`.

Итак, вот мои вопросы:

1) действительно ли создается новый контекст и вызывается новый bean-компонент everytime ejbCreate()?

2) если да, то что происходит с контекстом/компонентами, созданными в предыдущем вызове (например, если сами компоненты являются одноэлементными, будут ли они уничтожены)?

3) это правильный способ использования SingletonBeanFactoryLocator (возможно, из-за проблем с безопасностью потоков) в контексте выше?

4) если нет, то как является правильным способом его использования?

РЕДАКТИРОВАТЬ: одна из возможностей, о которой я могу думать, - это сделать соответствующие bean-компоненты prototype, чтобы сделать каждый экземпляр MDB потокобезопасным, поэтому нет необходимости освобождать и воссоздавать контекст. Жду других комментариев/предложений.

java spring ejb
03.08.2012

Ответы:


1
  1. Да
  2. Ничего не произошло. Одни и те же объекты останутся в одних и тех же MDB. MDB все равно, и Spring на данный момент не в курсе.
  3. Это действительно зависит от обстоятельств использования. Если вы просто используете Spring для сборки объектов, и у каждой MDB должны быть свои экземпляры, тогда ответ — да.
  4. В зависимости от варианта использования SpringBeanAutowiringInterceptor может быть или не быть лучшей альтернативой.
  5. Прототип может быть сложным. Вы должны хорошо понимать свои компоненты и последствия, чтобы заставить их делать то, что вы ожидаете. Вот почему, как правило, лучше всего сделать бины без гражданства.

Обновление: на самом деле существует состояние гонки. Если контейнер решит запустить ejbCreate() двух MDB параллельно, то они оба в конечном итоге будут совместно использовать один и тот же контекст приложения.

Обновление 2: мне не удалось найти раздел, который явно разрешает создание EJB через параллельные потоки, но я также не смог найти раздел, который явно запрещает это.

Учитывая следующие разделы спецификации, я предполагаю, что это было бы в духе спецификации.

2.4.2 Объекты, управляемые сообщениями

Типичный EJB-контейнер предоставляет масштабируемую среду выполнения для одновременного выполнения большого количества объектов, управляемых сообщениями.

5.2 Цели

Еще одна цель модели bean-компонентов, управляемых сообщениями, — обеспечить параллельную обработку потока сообщений посредством предоставляемого контейнером объединения экземпляров bean-компонентов, управляемых сообщениями.

5.4 Протокол между экземпляром компонента, управляемого сообщениями, и его контейнером

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

5.4.11 Параллелизм обработки сообщений

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

03.08.2012
  • Спасибо за ответ. Позволяет ли спецификация серверу создавать ejb через параллельные потоки? Не могли бы вы пл. дать ссылку на обновление в вашем ответе? 03.08.2012
  • Спасибо за реф. Предполагая, что может быть состояние гонки, одной из возможностей было бы сделать beanFactory статическим и загрузить его в статический блок, чтобы не было гонок. После этого в ejbCreate() он будет продолжать запрашивать соответствующие bean-компоненты, и если bean-прототипы здесь подходят, то нам не нужно закрывать и пересоздавать контекст для каждого ejbCreate. 06.08.2012
  • Вы можете добиться того же, не делая beanFactory статическим и закрывая его в методах @PreDestory вместо @PostConstruct. Это имеет несколько преимуществ, например, контекст уничтожается, как только все bean-компоненты не развернуты. 06.08.2012
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..