Как такое объединение экземпляров с EJB может улучшить производительность?

Question

Как этот пул экземпляров с EJB может улучшить производительность? Разве вы не смогли бы добиться такой же производительности только с потоками, подобными сервлету Java?

Или, возможно, объединение экземпляров с EJB происходит по другой причине?

Answer 1

Объединение экземпляров помогает не только потому, что вы можете повторно использовать объекты (и избежать дорогостоящего создания объектов), но и позволяет приложению. сервер правильно управляет загрузкой . Это приложение. для конкретного сервера, но обычно вы можете указать max-pool-size, min-pool-size, pool-resize и timeout.

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

Несколько замечаний о безопасности потоков :

Секта. 4.3.13 «Сериализация методов сессионных компонентов»

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

Согласно спецификации EJB, все запросы к конкретному экземпляру bean-компонента синхронизируются приложением. сервер. Это, например, позволяет сессионному компоненту без состояния (SLSB) сохранять соединение с базой данных в одном из его полей. Поля SLSB должны быть кратковременными. (Экземпляр компонента может быть уничтожен / создан заново в любое время.) Благодаря синхронизации приложение. сервер гарантирует, что SLSB является поточно-ориентированным. Без синхронизации с приложением. сервер, разработчик должен убедиться, что SLSB является поточно-ориентированным, то есть он не должен иметь полей.

Примечание. Редко иметь поля в SLSB. Большинство SLSB по своей природе потокобезопасны. Я бы не рекомендовал хранить соединение в поле, например. Лучше получить один в методе и выпустить его как можно скорее.

Answer 2

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

Если сам bean-объект дешев и его создание сопряжено с затратами на выполняемую работу, то объединение экземпляров не стоит хлопот.

Answer 3

AFAIK фундаментальная причина - другая модель потоков по сравнению с сервлетом. В случае сервлета существует только один экземпляр, и многие потоки могут одновременно работать с этим экземпляром. Разработчики несут ответственность за обеспечение правильной синхронизации.

В отличие от этого, контейнер ejb позволяет одновременно работать только одному потоку с экземпляром компонента (включая необходимую синхронизацию в фоновом режиме). Благодаря этому разработчику не нужно заботиться о синхронизации, и более того, использование синхронизации в коде компонента запрещено спецификацией (на самом деле вы можете это сделать, но вы должны учитывать последствия для производительности). Таким образом, чтобы включить параллельную обработку, вам нужно объединить несколько экземпляров бинов, чтобы несколько потоков могли обращаться к ним одновременно. Размер пула можно настроить в зависимости от того, какая работа выполняется внутри компонента. Основное правило: если задача связана с вводом / выводом, вам нужен большой пул, чтобы время процессора не было потеряно при ожидании ответа ввода / вывода. Если задача связана с процессором, пул должен быть таким же большим, как много процессоров / ядер на машине. Но настройка должна основываться на измерениях.

Еще одно замечание о сервлетах: вы можете применять то же поведение, что и ejb, при использовании интерфейса SingleThreadModel. Но на самом деле это не так уж и много.

Answer 4

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

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