16+
ComputerPrice
НА ГЛАВНУЮ СТАТЬИ НОВОСТИ О НАС




Яндекс цитирования


Версия для печати

Модуль поиска не установлен.

О компонентах Enterprise JavaBeans

09.09.2003

Антон Тульчинский, <antontul@rambler.ru>


Введение

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

EJB-технология позволяет разработчику моделировать широкий диапазон объектов, используемых в масштабах предприятия, определяя два типа EJB-компонентов: Session Beans и Entity Beans. Session Beans отображают сессии клиента - например, совершение пользователем транзакции с помощью сайта. Entity Beans отображают сущности - например, ряды в реляционной базе данных, и содержат операции с представляемыми данными. Entity Beans предназначены для обеспечения устойчивости и сохранности данных, с которыми они связаны, в течение всего их жизненного цикла. J2EE расширяет возможности и переносимость EJB-компонентов, определяя всю инфраструктуру, которая включает стандартные клиенты и API-сервисы для работы с ними.

Недостатки EJB

Как ни странно, я бы хотел начать с недостатков технологии Enterprise JavaBeans. Дело в том, что практически все авторы, пишущие о EJB, говорят о свойствах масштабируемости и универсальности, независимости архитектуры, совместимости и переносимости технологии EJB. Конечно, в той или иной степени это справедливо. Но давайте посмотрим и на отрицательные стороны.

Недостаток 1. Большая по объему и сложная спецификация. Надо сказать, что это не вина компании Sun, разработавшей спецификацию. Ни одна из существующих спецификаций, описывающих распределенную систему вычислений, не страдает лаконичностью. Для примера можно взять спецификацию стандарта CORBA от консорциума OMG (Object Management Group) или архитектуру .Net компании Microsoft. Тем не менее, хотелось бы, чтобы спецификация предоставляла несколько вариантов прочтения в зависимости от объема необходимой информации. Например, EJB-разработчикам требуется прочесть только содержание глав 6 и 9, для того чтобы понять, что такое session и entity beans.

Недостаток 2. Потенциальная угроза переусложнения решения. Этот недостаток тесно связан со сложностью спецификации. Грубо говоря, наличествует ситуация, что "либо ты, либо тебя". Иными словами, если вы не понимаете в достаточной степени идеологию EJB, вам не удастся эффективно ее использовать, и, скорее всего, вы только переусложните проект. Более того, велик риск, что вы, не понимая всех взаимосвязей, существующих между компонентами, решите реализовать или переписать какие-либо подсистемы самостоятельно, что приведет к потере переносимости, масштабируемости или просто к серьезным, трудно отлаживаемым ошибкам.

Недостаток 3. Постоянные изменения спецификации. Поскольку EJB - очень быстро развивающаяся технология, то неизбежны случаи, когда написанный код успевает к моменту выхода уже устареть, так как выходят новые версии спецификации, причем далеко не всегда сохраняющие обратную совместимость. В первую очередь это касается разработчиков контейнеров/серверов. К сожалению, такая ситуация неизбежна, и вам придется смириться с тем, что написанный EJB-код придется довольно часто пересматривать на соответствие с последней версией спецификации. Новые версии серверов приложений выходят достаточно часто, что совершенно несравнимо, скажем, с частотой появления новых версий СУБД. Такая ситуация довольно серьезно влияет на стоимость решения на базе EJB, т.к. сервера приложений относятся к достаточно дорогостоящему ПО, и следует заранее заложить в бюджет средства для обновления версий используемого сервера приложений.

Недостаток 4. Повышенная сложность по сравнению с обычным java-кодом. Даже на первый взгляд EJB-код достаточно сложен, так, для реализации каждого session bean, вы должны написать 3 класса, 4 класса на каждый entity bean, кроме того, для снижения трафика вам может понадобиться реализовать дополнительные объекты - значения (value objects). И при этом я еще не упомянул deployment descriptors, один стандартный, описывающий необходимые по спецификации свойства, и второй, содержащий свойства, специфичные для конкретного сервера приложений.

Решение этой проблемы - средства автоматической генерации кода. Большинство современных средств разработки (IDE) поддерживают авто-генерацию кода и размещение его на ряде популярных серверов приложений. К недостаткам использования IDE следует отнести привязку к определенному серверу приложений, а также возможность генерации кода только с использованием пользовательского интерфейса, что означает невозможность использования средств автогенерации кода в пакетном режиме, например при написании автоматических тестов или для автоматической сборки (build) приложения.

Компонентная модель

Для того чтобы понять, что же на самом деле такое, эти компоненты EJB, необходимо усвоить некоторые идеи компонентной модели. Следует уяснить: если вы используете компонентную модель, значит, строительными блоками модели являются компоненты, имеющие стандартный внешний вид, с помощью которого можно эти компоненты состыковывать. Другими словами, если вы будете использовать такую модель, вам необходимо строго придерживаться стандартов, описывающих внешний вид ваших компонентов. Внутренности ваших компонентов - это ваша проблема, вы вольны реализовывать функционал, как вам угодно, правда, есть некоторые рекомендации, которые вам принесут больше пользы, чем вреда.

Когда у клиента EJB возникает потребность воспользоваться услугами EJB, он с помощью home-интерфейса создаёт EJB. Клиент использует один из методов create(), которые определяет home-интерфейс. Реализация home-интерфейса осуществляется с помощью объекта, называющегося home-объектом. Экземпляр такого home-объекта создаётся на сервере и в качестве factory (построителя) предоставляется клиенту для создания бина. Давайте более детально рассмотрим этот процесс.

Взаимодействие клиента с компонентами EJB

Рассмотрим стандартный сценарий взаимодействия клиента с компонентами EJB.

1. Клиент ищет home-интерфейс нужного ему компонента по его имени через сервис имен JNDI (клиенту возвращается в результате поиска Home-интерфейс этого найденного компонента).

2. Клиент, через найденный home-интерфейс, вызывает функцию создания экземпляра компонента на стороне сервера (клиенту возвращается Remote-интерфейс созданного экземпляра компонента).

2.1: Сервер создает этот экземпляр.

3. Клиент вызывает бизнес-метод на созданном компоненте через Remote-интерфейс этого компонента.

3.1: Сервер вызывает бизнес-метод на конкретном экземпляре компонента.

Клиент EJB определяет местонахождение home-объекта с помощью JNDI (интерфейс Java Naming and Directory Interface), так как ссылка на этот home-объект помещается в службе имён (naming service). Соответствующее местоположение и имя factory-класса для контекста JNDI предоставляется клиенту изначально. Кроме знания места и имени класса, клиент должен иметь представление о том, как найти этот home-объект в структуре дерева имён (naming tree).

Когда специалист по внедрению EJB устанавливает и запускает компонент EJB на сервере EJB, он или она должны указывать конкретное место расположения на дереве имён, типа "cup/chap8/Account". Затем клиент EJB должен получить это полное имя для установления местонахождения, чтобы получить ссылку на home-объект "Account".

Кусок кода, с помощью которого клиент создаёт бин, используя home-объект, будет выглядеть приблизительно так:

// get the JNDI naming context
Context initialCtx = new InitialContext ();
// use the context to lookup the EJB Home interface
AccountHome home =(AccountHome)initialCtx.lookup ("com/~gopalan/Account");
// use the Home Interface to create a Session bean object
Account account = home.create (1234, "Athul", 1000671.54d);

Примеры интерфейсов

Home-объект - это реализация интерфейса, который расширяет интерфейс javax.ejb.EJBHome. В нём есть необходимые для работы методы create(), find() и remove(), каждый из которых соответствует ejbCreate(), ejbFind() and ejbRemove(), с той же сигнатурой, что указана в реализации конкретного создаваемого бина. Также здесь представлены методы для получения метаданных этого бина. А интерфейс EJBHome определяется в спецификации так:

public interface javax.ejb.EJBHome extends Remote {
public abstract void remove (Handle handle)
throws RemoteException, RemoveException;
public abstract void remove (Object primaryKey)
throws RemoteException,RemoveException;
public abstract EJBMetaData getEJBMetaData ()
throws RemoteException;
}

Разработчику EJB нужно будет в своих бинах определить методы ejbCreate(). Кроме этого он также должен определить имеющиеся методы create(), соответствующие сигнатурам, указанным в home-интерфейсе бина EJB. Если разработчик кодирует entity-бин, то он или она вероятно должны будут определить также в home-интерфейсе методы для поиска, которые позволят клиенту определять местонахождение имеющихся entity-бинов в соответствии с их идентификаторами.

Описание обычного home-интерфейса для компонента EJB может выглядеть так:

import javax.ejb.*;
import java.rmi.*;

public interface AccountHome extends EJBHome {
Account create(int accountNo, String customer)
throws CreateException, RemoteException;
Account create(int accountNo, String customer1, double startingBalance)
throws CreateException, RemoteException;
Account findByPrimaryKey(AccountPK accountNo)
throws FinderException, RemoteException;
}

Разработчик EJB должен также создать remote-интерфейс, который описывает бизнес-методы бина, которыми сможет пользоваться клиент EJB. EJBObject получит код реализации, сгенерированный для этого интерфейса инструментальными средствами контейнера. Имена методов и их сигнатуры, указанные в remote-интерфейсе, должны в точности соответствовать именам и сигнатурам бизнес-методов, указанным в бине, в отличие от home-интерфейса, когда совпадают только сигнатуры методов, а их имена отличаются. Описание обычного remote-интерфейса для компонента EJB будет выглядеть так:

import javax.ejb.*;
import java.rmi.*;

public interface Account extends EJBObject {
void credit (double amount) throws RemoteException;
void debit (double amount) throws RemoteException;
double getBalance () throws RemoteException;
}

EJBObject - это видимый в сети объект с собственной стуктурой и наполнением, действующий как proxy бина. Имеющийся у бина remote-интерфейс расширяет интерфейс javax.ejb.EJBObject, делая, таким образом, класс EJBObject специфическим для данного класса бина. Для каждого бина EJB существует стандартный класс EJBObject.

Enterprise-бины

Компонент EJB - это отрезок кода, имеющий поля и методы для реализации каждого модуля бизнес-логики. Они могут быть как постоянными, так и непостоянными. Мы можем говорить о наличии двух видов enterprise-бинов:

1. Entity-бины - компоненты, предназначенные для моделирования бизнес-объектов.

2. Session-бины - компоненты общего назначения для работы на серверной стороне.

Enterprise-бины представляют собой строительный материал, конструктивные элементы, которые могут использоваться как самостоятельно, так и в сочетании с другими бинами в целях создания сложных, надёжных, многоуровневых тонко-клиентских приложений.

Прежде чем мы перейдём к обсуждению этих бинов, необходимо понять концепцию активизации и перевода в пассивное состояние (activation и passivation). Перевод в пассивное состояние - это процесс, цель которого сохранить состояние бина в базе данных для последующего использования. Активизация - это процесс, в результате которого устанавливается состояние бина с помощью получения данных из перманентной базы данных.

Пример bean-компонента и его XML-описания

В EJB 2.0 управляемый контейнером entity-бин определяется как абстрактный, а его персистентные поля не определяются напрямую в классе бина. Вместо этого, была разработана абстрактная схема персистентности, которая позволяет разработчику бина декларировать персистентные поля и связи бина косвенно. Ниже приводится пример bean-компонента Employee, в котором используется новая схема персистентности. Обратите внимание на то, что ни одно из персистентных полей не задекларировано в классе компонента.

public abstract EmployeeBean implements javax.ejb.EntityBean {
. // instance fields
EntityContext ejbContext;

// container-managed persistent fields
public abstract void setIdentity(int identity);
public abstract int getIdentity();
public abstract void setFirstName(String firstName);
public abstract String getFirstName();
public abstract void setLastName(String lastName);
public abstract String getLastName();

// container-managed relationship fields
public abstract void setContactInfo(ContactInfo info);
public abstract ContactInfo getContactInfo();
...
}

В XML-описании применения данного бина схема персистентности декларирует управляемые контейнером поля и связи.

<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>EmployeeEJB</ejb-name>
...
<persistence-type>Container</persistence-type>
...
<cmp-field><field-name>identity</field-name></cmp-field>
<cmp-field><field-name>firstName</field-name></cmp-field>
<cmp-field><field-name>lastName</field-name></cmp-field>
...
</entity>
</enterprise-beans>
<dependents>
<dependent>
<dependent-class>ContactInfo</dependent-class>
<dependent-name>ContactInfo</dependent-name>
<cmp-field>street</cmp-field>
<cmp-field>city</cmp-field>
<cmp-field>state</cmp-field>
<cmp-field>zip</cmp-field>
<cmp-field>homePhone</cmp-field>
<cmp-field>workPhone</cmp-field>
<cmp-field>email</cmp-field>
...
</dependent>
<relationships>
<ejb-relation>
<ejb-relation-name>Employee-ContactInfo</ejb-relation-name>
<ejb-relationship-role>
<ejb-relationship-role-name>
employee-has-contactinfo
</ejb-relationship-role-name>
<multiplicity>one</multiplicity>
<role-source>
<ejb-name>EmployeeEJB</ejb-name>
</role-source>
<cmr-field>
<cmr-field-name>contactInfo</cmr-field-name>
<cmr-field-type>ContactInfo</cmr-field-type>
</cmr-field>
</ejb-relationship-role>
<ejb-relationship-role>
<ejb-relationship-role-name>
contactinfo_belongsto_employee
</ejb-relationship-role-name>
<multiplicity>one</multiplicity>
<role-source>
<dependent-name>ContactInfo<dependent-name>
</role-source>
</ejb-relationship-role>
</ejb-relation>
</relationships>
<ejb-jar>

Элементы XML, используемые для описания управляемых контейнером взаимосвязей, могут становиться достаточно сложными, поскольку им приходится иметь дело как с множественностью, так и с направленностью (однонаправленностью и двунаправленностью) этих связей. В приведенном ниже отрывке кода показаны элементы, которые могут вам понадобиться для описания простого взаимодействия между бином и классом зависимого от него объекта. И хотя даже такие простые отношения транслируются в "многословный" XML, все эти элементы необходимы для того, чтобы "persistence manager" смог распределить сложные объектные структуры по базе данных.

Пакетирование

Компоненты Enterprise JavaBeans могут упаковываться как отдельные enterprise beans, набор enterprise beans, либо как законченная система приложений. Компоненты Enterprise JavaBeans запаковываются в Java Archive File, называемый ejb-jar file. Файл ejb-jar содержит файл manifest, представляющий содержание данного файла, а также файлы классов enterprise bean, объекты Deployment Descriptor и, на ваше усмотрение, объекты Environment Properties.

Deployment Descriptors

Объекты Deployment Descriptor используются для задания условий выполнения enterprise bean. Данные установки сообщают контейнеру EJB, как контролировать и управлять enterprise bean. Установки могут задаваться во время создания или установки приложения.

Объект DeploymentDescriptor описывает, как создавать и поддерживать в рабочем состоянии объект Enterprise Bean. Кроме всего прочего, данный объект определяет название класса этого enterprise bean, пространство имён JNDI, представляющее контейнер, название интерфейса Home, название интерфейса Remote и название объекта Environment Properties. Объект DeploymentDescriptor содержит массив объектов ControlDescriptor, определяющих семантику транзакций, которую необходимо применить к enterprise bean, и массив объектов AccessControlEntry, определяющих правила защиты, которые следует применить к enterprise bean.

Session beans и entity beans, в принципе, имеют одинаковые требования; поэтому существует два различных типа deployment descriptors. Объект SessionDescriptor расширяет объект DeploymentDescriptor и добавляет атрибуты, указывающие на то, имеет ли session bean состояние или нет. Объект EntityDescriptor расширяет объект DeploymentDescriptor и добавляет атрибуты, указывающие, какие поля внутри объекта должны сохраняться неизменными контейнером автоматически.

Entity-бины

Еntity-бин представляет собой перманентные данные, хранящиеся в структуре домена, а также методы для обработки этих данных. Если быть ещё более точным, то entity-бин указывает путь к конкретным данным в модели домена. В контексте релятивных баз данных, для каждой строки таблицы существует свой отдельный бин. Эта концепция не нова, так построены все объектные базы данных. Каждый entity-бин определяется своим первичным ключом. Entity-бины создаются с помощью построителя объектов (object factory) - метода create(). Эти бины также либо сами перманентны, либо передают эту функцию своему контейнеру.

Entity-бины всегда имеют какое-либо состояние, которое может быть зафиксировано и сохранено. С другой стороны, одним entity-бином могут пользоваться сразу несколько клиентов EJB одновременно. Срок действия бина ничем не ограничен, даже жизненным циклом виртуальной машины, в рамках которой он выполняется. Сбой виртуальной машины может только стать сигналом начала процедуры возврата в исходное состояние (rollback) текущей транзакции, но не сможет ни уничтожить сам бин, ни изменить ссылку, по которой к нему обращаются клиенты. Более того, клиент сможет обратиться к бину позднее, пользуясь той же ссылкой, так как она содержит уникальный для бина первичный ключ, позволяющий enterprise-бину или его контейнеру перезагружать его состояние. Таким образом, entity-бинам не страшны системные сбои или отключения.

Персистентность entity-бинов может быть двух видов:

1. Персистентность, управляемая контейнером (Container-managed persistence): в этом случае за сохранение состояния entity-бина отвечает контейнер EJB. Здесь реализация бина будет зависеть от источника данных. Все управляемые контейнером поля должны быть, тем не менее, указаны в описании установки и внедрения (deployment descriptor), чтобы контейнер осуществлял управление персистентностью автоматически.

2. Персистентность, управляемая бином (Bean-managed persistence): в этом же случае, сам бин отвечает за сохранность своего состояния, а контейнеру не нужно генерировать никакие обращения к базе данных. Следовательно, данная имплементация менее гибка, чем предыдущая, так как требует, чтобы отвечающий за это код был частью кода бина.

Итак, каждый entity-бин должен обладать следующими характеристиками:

К еntity-бинам может обращаться одновременно большое количество пользователей.

Entity-бины могут участвовать в транзакциях.

Entity-бины представляют данные в структуре домена.

Entity-бины перманентны. Они существуют до тех пор, пока существуют данные в структуре домена.

Entity-бины не подвергаются влиянию системных сбоев. Клиент не теряет данные в результате сбоя или отключения сервера EJB.

Entity-бины имеют постоянные объектные ссылки, которые содержат неизменяемый ключ данного бина.

Session-бины

Session-бин создаётся клиентом и в большинстве случаев существует только на протяжении срока выполнения одного сеанса. Он осуществляет операции от лица клиента. В число таких операций входят обращение к базе данных или выполнение числовых операций в соответствии с какими-либо формулами. Хотя эти бины могут быть транзактными, они не восстанавливаются после системного сбоя. Они могут не иметь состояния или поддерживать диалоговое состояние среди методов и транзакций. Контейнер управляет диалоговым состоянием session-бина, если тот должен быть удалён из памяти. Session-бин должен сам управлять своей персистентностью.

Каждый session-бин обычно связан с одним клиентом EJB, отвечающим за его создание и удаление. Таким образом, session-бины являются "смертными" и не могут пережить виртуальную машину, в которой они создаются. Бин может либо сохранять своё состояние, либо оставаться без него. И кроме того, они "умирают" при системных сбоях или отключениях.

Существует два вида session-бинов:

Не имеющие состояния (Stateless session beans): бины данного типа не имеют внутреннего состояния. Исходя из этого факта, такие бины не нуждаются в процедуре перевода в пассивное состояние и могут использоваться для обслуживания большого количества клиентов.

Имеющие состояние (Stateful session beans): бины этого типа имеют внутреннее состояние, а следовательно, должны подвергаться переводу в пассивное или активное состояние. Так как они могут сохранять своё состояние, они могут также называться persistent session beans. Для каждого такого session-бина может существовать только один клиент EJB. Такие бины могут сохраняться и восстанавливаться в процессе клиентских сеансов. Метод getHandle() возвращает обработанный экземпляр объекта бина, который может использоваться для хранения состояния бина. Впоследствии для повторного получения бина из перманентной базы вызывается метод getEJBObject(),

Характеристики, присущие session-бинам, можно сформулировать следующим образом:

Session-бины работают от лица отдельных клиентов. Экземпляр такого бина является расширением клиента, который его создаёт.

Session-бины могут хранить информацию о транзакциях.

Session-бины могут обновлять данные в соответствующей базе данных.

Session-бины относительно недолговечны. Жизненный цикл не имеющего состояния бина ограничен циклом его клиента.

Session-бины могут погибать в результате сбоев сервера EJB. Чтобы продолжить вычисления, клиент должен устанавливать связь с новым объектом session-бина.

Session-бины не представляют данных, которые должны сохраняться в базе данных.

Каждый session-бин может читать и обновлять базу данных от лица клиента. Его поля могут содержать диалоговое состояние клиента. Это состояние описывает диалог, представленный специфической клиент/серверной парой. В процессе транзакции часть этой информации может сохраняться в кэше бина.

Session-бины по сути являются закрытыми ресурсами, использующимися исключительно клиентами, которые их создали. По этой причине session-бин прячет свой идентификатор и остаётся анонимным, что совершенно отличается от природы entity-бина, который демонстрирует себя с помощью первичного ключа.

Средства защиты En terprise JavaBeans

Модель Enterprise JavaBeans использует сервисы средств защиты на Java, поддерживаемые в Java Development Kit. Средства защиты Java-платформы поддерживают сервисы аутентификации и авторизации, ограничивающие доступ к защищённым объектам и методам.

Кроме того, технология Enterprise JavaBeans автоматизирует процесс использования средств защиты Java-платформы, чтобы не было необходимости для enterprise beans непосредственно кодировать рутинные процессы Java-средств защиты. Правила защиты для каждого enterprise bean определены декларативно в пакете объектов AccessControlEntry в объекте deployment descriptor. Объект AccessControlEntry сопоставляет метод со списком пользователей, которые имеют права на вызов метода. Контейнер EJB использует AccessControlEntry для автоматического выполнения всех мер защиты, необходимых enterprise bean.

Транзакции

Несмотря на то что технология Enterprise JavaBeans может вполне использоваться для реализации систем, не поддерживающих транзакции, данная модель была разработана для поддержки распределённых транзакций. Технология Enterprise JavaBeans требует использования распределённой системы управления транзакциями, которая поддерживает протоколы двухфазовой фиксации распределённых транзакций.

Спецификация Enterprise JavaBeans предусматривает, но не требует осуществления транзакций, основанных на Java Transaction Service (JTS) API. JTS представляет собой Java-технологию, связанную с CORBA Object Transaction Service (OTS). JTS поддерживает распределённые транзакции, которые могут охватывать множество баз данных на многочисленных системах, координируемых многочисленными менеджерами транзакций. Используя JTS, сервер Enterprise JavaBeans гарантирует, что его транзакции могут охватывать многие серверы Enterprise JavaBeans.

Приложения Enterprise JavaBeans взаимодействуют с сервисом транзакций посредством Java Transaction API (JTA). JTA обеспечивает программный интерфейс для запуска транзакций, подключения существующих транзакций, выполнения транзакций и откатки транзакций.

Хотя разграничение транзакций в централизованном приложении является довольно простым процессом, он усложняется, когда приложение состоит из переменного числа автономных компонентов приложений, которые ссылаются друг на друга. Технология Enterprise JavaBeans значительно упрощает процесс разработки приложений, автоматизируя использование распределённых транзакций. Все функции транзакций могут выполняться непосредственно EJB-контейнером и EJB-сервером. Отдельным enterprise beans нет необходимости создавать операторы разграничения транзакций, включая их в код. И поскольку код транзакций требуется для логики приложений, enterprise beans проще писать и переносить посредством различных менеджеров транзакций.

Семантика транзакций enterprise bean определена скорее не программно, а декларативно. Во время выполнения EJB контейнер автоматически реализует сервисы транзакций в соответствии с атрибутом TransactionAttribute, определённым в объекте deployment descriptor.

Модель Enterprise JavaBeans подчиняется шести правилам транзакций:

- TX_BEAN_MANAGED.

Установка TX_BEAN_MANAGED означает, что enterprise bean самостоятельно выполняет контроль за своими собственными транзакциями. EJB поддерживает разграничение транзакций вручную через Java Transaction API.

- TX_NOT_SUPPORTED.

Установка TX_NOT_SUPPORTED означает, что enterprise bean не может выполняться в контексте транзакции. Если клиент (т.е. всё, что вызывает метод, - либо удалённый клиент, либо другой enterprise bean) имеет транзакцию, когда он вызывает enterprise bean, контейнер прекращает данную транзакцию во время вызова метода.

- TX_SUPPORTS.

Установка TX_SUPPORTS означает, что enterprise bean может выполняться как с контекстом транзакций, так и без него. Если клиент имеет транзакцию, когда вызывает enterprise bean, данный метод присоединится к контексту транзакций клиента. Если клиент не имеет транзакции, данный метод будет выполняться без транзакции.

- TX_REQUIRED. У

становка TX_REQUIRED означает, что enterprise bean должен работать в контексте транзакции. Если клиент имеет транзакцию, когда он вызывает enterprise bean, данный метод присоединится к контексту транзакций клиента. Если клиент не имеет транзакции, контейнер автоматически запускает новую транзакцию для этого метода.

- TX_REQUIRES_NEW.

Установка TX_REQUIRES_NEW означает, что enterprise bean выполняется в контексте новой транзакции. Контейнер всегда начинает новую транзакцию для данного метода. Если клиент имеет транзакцию, когда вызывает enterprise bean, контейнер прекращает транзакцию клиента на время вызова метода.

- TX_MANDATORY.

Установка TX_MANDATORY означает, что enterprise bean всегда работает в контексте транзакции клиента. Если клиент не имеет транзакции, когда вызывает enterprise bean, контейнер выбрасывает TransactionRequired exception и запрос не выполняется.

В завершение отмечу, что двухфазный протокол фиксации транзакций служит для обеспечения сохранения результата транзакции или отмены задания. В первой фазе JTS устанавливает готовность каждого из менеджеров ресурсов. Если каждый из них подтверждает свою готовность, то во второй фазе JTS передаёт каждому из них сообщение о фиксации результата. Если какой-либо из менеджеров не отвечает на запрос или даёт отрицательный ответ, JTS оповещает остальных менеждеров о том, что транзакция отменяется.



статьи
статьи
 / 
новости
новости
 / 
контакты
контакты