Таким образом, сеансовый компонент может в готовом виде получать от контейнера EJB временную разметку транзакции, но в то же время иметь возможность нестандартно обрабатывать специфические ситуации. Все три метода, показанные на рис. 12.7, рассматриваются и моделируются как любые другие методы жизненного цикла сеансового компонента.
|
|
нии существования этого компонента. На самом деле эти методы определяются объектом userTransaction, получаемым от объекта ejbContext. Объект ejbContext предоставляет методы, с помощью которых EJB может обращаться к среде выполнения из контейнера, в котором он работает.
Ограничения сеансовых компонентов, не имеющих состояний
Для сеансовых компонентов без состояний возможна демаркация транзакций как с управлением от контейнера, так и с управлением от компонента, но реализация интерфейса SessionSynchronization не разрешается. Есть еще одно ограничение: в сеансовых объектах, не сохраняющих диалоговое состояние, не допускаются транзакции, которые охватывают более одного диалогового метода. Отсюда видно, что сеансовые компоненты без состояний могут быть реально полезными только для обработки относительно небольших и простых транзакций. Более сложным транзакциям требуется полный набор возможностей, который есть только у сеансовых компонентов с поддержкой состояний.
Атрибуты транзакции
Как было сказано ранее, в случае демаркации с управлением от контейнера с каждым методом EJB связывается атрибут транзакции, который указывается в описателе развертывания EJB. При каждом вызове данного метода эти атрибуты указывают контейнеру EJB, как следует управлять транзакцией клиента. Атрибут требуется почти для всех определяемых пользователем методов EJB, но несколько унаследованных методов, которые всегда присутствуют в EJB, не могут использовать эту настройку.
Настройки атрибутов транзакции в основном сообщают контейнеру EJB, следует ли выполнить метод в транзакции клиента, создать новую транзакцию или выполнить метод без транзакции. Выполнение в транзакции подразумевает использование контекста транзакции. Этот контекст необходим в случаях, когда метод EJB требует доступа к диспетчерам ресурсов, или при работе с персистентным состоянием EJB.
Атрибуты транзакции применяются для всех деловых методов сеансовых компонентов, включаемых в удаленный интерфейс. Ниже перечислены основные значения атрибутов и их смысл.
· NotSupported. Указывает, что данный метод выполняется без контекста транзакции. Если такой контекст был задан, он игнорируется на время выполнения метода и восстанавливается после его завершения.
· Required. Указывает, что данный метод выполняется с контекстом транзакции.Если контекст не задан, на время выполнения метода создается новый контекст.
· Supported. Если метод вызывается без контекста, он работает, как с атрибутом NotSupported. Если метод вызывается с контекстом, он выполняется, как с атрибутом Required.
· RequiresNew. Этот метод выполняется с новым контекстом транзакции, созданным специально для него. Если контекст был задан, он игнорируется на время выполнения метода и восстанавливается после его завершения.
· Mandatory. Этот метод выполняется с контекстом транзакции. Если контекст незадан, генерируется исключительная ситуация.
· Never. Этот метод выполняется без контекста транзакции. Если контекст задан, генерируется исключительная ситуация.
Транзакции EJB могут управляться компонентом или контейнером. Хотя на низком уровне, скрытом от разработчика, эти подходы идентичны, с точки зрения разработки они различаются по видимым деталям и особенностям управления.
Для транзакций, управляемых компонентом, их границы легко показать наглядно, изобразив вовлеченные в них операции на диаграмме последовательностей или сотрудничества. Это хорошо видно на рис. 12.7.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.
