EJB-@Singleton для управления результатами запроса

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

Сценарий I:

Пользователь начинает Web-сеанс и выполняет запросы к базе данных для просмотра статистики или данных. Эти запросы выполняются в течение сеанса. Таким образом, 10.000 пользователей сделали бы 10.000 равных запросов к базе данных.

Сценарий II:

Пользователь начинает веб-сессию и повторяет данные для статистики или данных из предварительно инициализированного @Singleton-Bean. @Singleton (javax.ejb.Singleton) сделал запрос в начале запуска сервера (@Startup). Таким образом, 10.000 пользователей могут читать из ОДНОГО кеша (@Singleton) и не должны запрашивать базу данных. My @Singleton-Bean запускает обновление своих кэшированных данных, если кто-то еще создает / редактирует / удаляет данные.

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

  • Сценарий II масштабируется лучше, чем сценарий I? Я думаю да. Я прав?
  • Есть ли еще какие-то предостережения или вещи, которые следует учитывать?
  • Я знаю, что Stateless-Beans масштабируется гораздо больше, чем @stateful или @Singleton. Стоит ли использовать @Stateless-Bean и кэшировать запросы чем-то вроде JPA/Hibernate Caches.
  • Должен ли я использовать @ApplicationScoped (javax.enterprise.context) вместо @Singleton (javax.ejb.Singleton), чтобы использовать прокси? Было бы лучше?

1 ответ

Да, сценарий 2 масштабируется лучше, чем 1, мы говорим об эффективности здесь.

Для кэширования сущностей лучше использовать нижний уровень, то есть уровень постоянства, просто потому, что это его работа.

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

Другие вопросы по тегам