Изучаем Java EE 7

5. Объект больше не нужен контейнеру. Последний вызывает метод с аннотацией @PreDestroy, если таковой имеется, и заканчивает жизненный цикл экземпляра компонента.

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

Рис. 8.1. Жизненный цикл сеансовых компонентов, не хранящих состояния, и синглтонов

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

Примечание

Контроль над EJB может производиться с помощью консоли управления GlassFish (GlassFish Administration Console). GlassFish затем позволяет настроить несколько параметров хранилища EJB. Вы можете установить размер хранилища (исходное, минимальное и максимальное количество компонентов в хранилище), количество компонентов, которые необходимо удалить при превышении времени простоя. Вы также можете задать количество миллисекунд, по прошествии которых будут удаляться объекты. Наличие этих настроек зависит от реализации; некоторые из них могут быть недоступны для других контейнеров EJB.

Создание сеансовых синглтонов зависит от того, как был создан экземпляр (с аннотацией @StartUp или без), а также от того, зависит ли он (@DependsOn) от синглтона, который был создан с этой аннотацией. Если ответ — «да», то контейнер создаст экземпляр во время развертывания. Если — «нет», то контейнер создаст экземпляр в тот момент, когда клиент вызовет бизнес-метод. Поскольку синглтоны существуют во время работы приложения, их экземпляры разрушаются при отключении контейнера.

Компоненты, хранящие состояние

Компоненты, хранящие состояние, программно незначительно отличаются от компонентов, не хранящих состояния, и синглтонов: меняются только метаданные (@Stateful вместо @Stateless или @Singleton). Реальное отличие заключается в том, что компоненты, хранящие состояние, поддерживают диалог с клиентом и, следовательно, имеют немного иной жизненный цикл. Контейнер создает экземпляр и назначает его только одному клиенту. Затем каждый запрос от клиента передается этому экземпляру. Следуя данному принципу, в зависимости от вашего приложения, вы в итоге можете прийти к соотношению «один к одному» между клиентом и сеансовым компонентом (например, тысяча пользователей, работающих одновременно, может создать тысячу компонентов, сохраняющих состояние). Если один из клиентов не вызывает экземпляр своего компонента в течение длительного промежутка времени, контейнер должен удалить его, чтобы у виртуальной машины не закончилась память, и при этом сохранить состояние экземпляра в постоянном хранилище, а затем вернуть экземпляр с этим состоянием, когда это необходимо. Контейнер использует прием пассивизации и активизации.

Пассивизация — это процесс, когда контейнер сериализует экземпляр компонента на постоянный носитель (файл на диске, база данных и т. д.), вместо того чтобы держать его в памяти. Активизация, которая является противоположностью этому процессу, выполняется, когда экземпляр компонента снова необходим клиенту. Контейнер десериализует компонент из постоянного хранилища и помещает его обратно в память. Это означает, что атрибуты компонента должны быть сериализуемыми (они должны иметь примитивный тип или реализовывать интерфейс java.io.Serializable). На рис. 8.2 показан жизненный цикл компонентов, сохраняющих состояние, он описывается следующим образом.

1. Жизненный цикл компонента, сохраняющего состояние, начинается, когда клиент запрашивает ссылку на компонент (с использованием внедрения зависимостей или поиска JNDI). Контейнер создает новые экземпляры сеансовых компонентов и сохраняет их в памяти.

2. Если вновь созданный экземпляр применяет внедрение зависимостей через аннотации (@Inject, @Resource, @EJB, @PersistenceContext и т. д.) или дескрипторы развертывания, контейнер внедряет все необходимые ресурсы.

3. Если экземпляр имеет метод с аннотацией @PostContruct, контейнер вызывает его.