Лучше всего визуализировать Stateful Session Bean (SfSB) как очень близкий к экземпляру обычного Java-класса. Вы ищите (или внедряете) экземпляр SfSB, и контейнер создаст его для вас и вернет экземпляр. Затем вы работаете с этим экземпляром, как и с любым другим экземпляром Java.
Это означает, что вы можете сохранить экземпляр в сеансе, сериализовать его на диск и т. Д.
Суть в том, что экземпляр, с которым вы работаете, на самом деле является прокси для фактического базового экземпляра SfSB. Это не настоящий SfSB.
Когда вы обращаетесь к локальному прокси-серверу с компонентом, задача контейнера заключается в том, чтобы передать этот компонент в память для вас. Пассивация и активация bean-компонента выполняются за кулисами (хотя вы можете подключиться к процессу через жизненный цикл bean-компонентов).
Любая информация, которая нужна контейнеру для поиска пассивированного SfSB, хранится в прокси, с которым вы работаете, но это непрозрачно для вас. Вам не нужно об этом беспокоиться.
Таким образом, в типичном веб-сценарии жизненный цикл состоит в том, что вы получаете свой экземпляр компонента, сохраняете его в веб-сеансе, а затем просто используете его как обычно. Если контейнер решит, что ему нужно пассивировать ваш компонент, чтобы освободить место или что-то еще, он автоматически пассивирует его для вас. Когда ваш пользователь возвращается, ваше приложение извлекает экземпляр из веб-сеанса и выполняет его вызовы. В то время, если компонент пассивируется, контейнер автоматически активирует компонент для вас. Весь этот механизм зависит от контейнера, но прозрачен для вас. Важно помнить, что вы должны привязываться к SfSB, который вы получаете из контейнера, так же, как и к любому Java-объекту.
Последнее замечание: если вы позволите пассивировать SfSB слишком долго, контейнер автоматически удалит его для вас.