Зачем объединять сессионные компоненты без сохранения состояния?

Question

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

С моей точки зрения, это не отличается от вызова метода одного и того же экземпляра отдельными потоками.Так почему же контейнер не может использовать один экземпляр компонента вместо объединения нескольких из них?

Answer 1

Объединение в пул делает несколько вещей.

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

Во-вторых, вы сокращаете потенциальное время запуска компонента.Хотя Session Beans не имеют состояния, они должны быть апатридами только по отношению к клиенту.Например, в EJB вы можете внедрить несколько серверных ресурсов в сеансовый компонент.Это состояние является частным для компонента, но нет причин, по которым вы не можете сохранять его от вызова к вызову.Таким образом, объединяя bean-компоненты в пул, вы сокращаете эти поиски до того, что они будут выполняться только при создании bean-компонента.

В-третьих, вы можете использовать пул компонентов как средство регулирования трафика.Если у вас в пуле только 10 Bean-компонентов, одновременно будет работать не более 10 запросов, остальные будут поставлены в очередь.

Answer 2

Объединение в пул повышает производительность.

Один экземпляр, обрабатывающий все запросы/потоки, приведет к большому количеству конфликтов и блокировок.

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

Контейнер может управлять размером пула в зависимости от фактической активности.

Answer 3

Транзакционность модели Java EE использует контекст потока для управления жизненным циклом транзакции.

Это упрощение существует для того, чтобы не было необходимости реализовывать какой-либо конкретный интерфейс для прямого взаимодействия с объектом UserTransaction;когда транзакция извлекается из InitialContext (или вводится в сеансовый компонент), она привязывается к локальной переменной потока для повторного использования (например, если метод в вашем сеансовом компоненте без сохранения состояния вызывает другой сеансовый компонент без сохранения состояния, который также использует внедренную транзакцию. )

Answer 4

Жизненный цикл сессионных bean-компонентов без сохранения состояния: состояния «Не существует», «Пассивный» и «MethodReady(Passive или Inactive»). Для оптимизации производительности вместо полного перемещения bean-компонента от состояния создания до состояния готовности метода контейнер управляет bean-компонентом между активным и пассивным состояниями через обратные вызовы контейнера — ejbActivate() и ejbPassivate(), управляя пулом компонентов.

сринут

Answer 5

Методы по своей природе ЯВЛЯЮТСЯ ПОТОКОВЫМИ (включая статические).Почему?Просто, потому что каждая переменная внутри метода создается в памяти стека, т.е.каждая переменная, используемая внутри метода, создается для каждого вызова (она не является общей).Однако параметры не являются частью стека.

Однако метод небезопасен, если он использует небезопасную переменную:

а) вызов статического поля или переменной.Однако это происходит в каждом отдельном случае.

б) вызов ресурса, который является общим.Например, EntityManager.

в) передача параметра, который небезопасен.