Здравствуйте, pandamima, Вы писали:

P>Имеется SFSB (Stateful Session Bean). Вот берем мы home reference, потом ejb object reference. Работаем с ним. Дальше мы его имеем возможность (теоретически и практически) заserialize'ить. И засунуть в файл или поле базы (к примеру).

P>Представим себе что мы это сделали. Засунули в файл или базу. Закончили application. Прошел час. Два. Три. День. Два. Три. Короче времени прошло.

P>Все это время application server не будет убивать SFSB? То есть бин постоянно будет ждать хозяина? Считается ли засерилизрованный референс как активный на бин?
P>Если таки будет ждать, то вопрос как долго? До перезагрузки application server? А если надо чтобы все выжило и после перезагрузки, что делать?
P>Если таки будет ждать, то какая есть возможность ограничить его жизнь например какой-нибудь инструкций сервера? А то ведь иначе прийдется "мочить" самому их — клиент то может больше времени не возвращаться, а может и вообще не возвращаться — значит есть много шансов (при большом количестве клиентов) конкретно засрать application server ожидающими.

читаем спеку вместе (ejb2.1, глава 7.1):

In the case of a stateful session bean, its lifetime is controlled by the client.
A container may also terminate a session bean instance’s life after a deployer-specified timeout
or as a result of the failure of the server on which the bean instance is running. For this
reason, a client should be prepared to recreate a new session object if it loses the one it is
using.
Typically, a session object’s conversational state is not written to the database. A session bean developer
simply stores it in the session bean instance’s fields and assumes its value is retained for the lifetime of
the instance.

что дает общий ответ на первые три вопроса:

фактически, спецификация не напрягает производителей контейнеров гарантировать хоть какую-то надежность по отношению к хранению состояния SFSB. т.е. если надо, разработчик сам беспокоится об этом и пишет соответствующий код, сохраняющий какие-то данные в БД.
т.е. "состояние SFSB" — это совокупное значение сериализуемых (не-transient) переменных, предусмотренных в классе реализации бина. будут ли эти значения сериализоваться куда-то в хранилище сервера после каждого запроса со стороны клиента — личная инициатива сервера. сервер может помогать в надежной кластеризации и прочее, но больших гарантий, все равно, не даст. что означает, что сбой сервера (в т.ч. перезагрузка) может привести к потере состояния бина. выход один — сохранять состояние самому и явно (в БД)
более того — обычно предусматиривается timeout (задаваемый, обычно, в настройках сервера, а также определяемый в вендор-зависимой части ejb-дескриптора), согласно которому контейнер по истечении срока имеет право уничтожить состояние бина.

сама по себе сериализация handle — нормальное желание. спека его поддерживает (см. главу 6.8), при этом не обязательно думать, что контейнер будет реализовывать активность бина непременно как наличие инстанса класса его имплементации. контейнер может иметь свое хранилище состояний, и при необходимости инстанс "уничтожать", а при следущем запросе клиента (который десериализовал handle и восстановил объектную ссылку), создавать новый инстанс, инициализируя его переменные, десериализуя их из своего внутреннего хранилища.

P>Или сериализация в файл или куда то еще не будет считается активным референсом на бина? То есть в таком случае единственный вариант сериализнуть лишь в HttpSession?

не важно, куда идет сериализация — контейнер не контролирует клиентов. пока он жив, он так или иначе сохранит состояние бина вплоть до истечения таймаута.

P>Предположим такое все работает. Но как будет в случае если один клиент (servlet) сериализнул в файл или поле базы, а другой клиент (swing application) десериализнул и собрался работать с этим EJBObject. Такое прокатит?

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