Entity Bean. Жизненный цикл

Entity-бины представляют собой бизнес-правила, оперирующие с (хранящиеся постоянно) данными в базе данных, причем к этим данным в условиях решаемой задачи должны иметь доступ многие пользователи. Так как инфо в Бд являетя постоянной, то Entity bean живут постоянно, выживая после сбоя серверов. Каждому Entity-бину соответствует свой первичный ключ, по которому он может быть однозначно определен клиентом. Также Entity-бин имеет всегда какое-либо состояние (набор величин атрибутов, определяющих данный Entity-бин), которое может быть зафиксировано и сохранено, а затем и восстановлено. Разделяют персистентность, управляемую контейнером (Container-managed persistence) и персистентность, управляемую самим бином (Bean-managed persistence). Отличие состоит в том, кто ответственен за сохранение состояния бина: в первом случае это контейнер EJB, во втором - сам бин. Первое более универсально и требует меньших затрат от разработчика EJB, второе требует написания отдельного кода в бине и используется, очевидно, когда первый способ по каким-либо причинам (скорость, необходимость специальной функциональности при сохранении состояния бина, etc.) разработчика не устраивает.

Жизненный цикл Entity-бина состоит из трех состояний:

а) Бин не существует;

б) Бин находится в "обобщенном" (pooled) режиме, куда сервер приложений по спецификации переводит набор бинов, задавая им метод setEntityContext(). Таким образом, в этом состоянии бин получил кое-какие признаки своего класса, но ещё не идентифицирован с определенным полем в СУБД;

в) Бин находится в "готовом" (ready) режиме, он идентифицирован с конкретными данными в базе данных.

Заметим, что Entity-бинам не страшны такие приятные неожиданности, как сбои в системе или виртуальной Java-машине (JVM). Такие ситуации приведут только к откату (rollback) текущей транзакции и не уничтожат сам бин, который восстановится позднее при включении системы и JVM, и тем более не изменят ссылку, по которой клиент обращается к бину через JNDI.