 | Уровень сложности: простой Михаил Генкин, разработчик решений, IBM
20.02.2008 Обработка транзакций является важнейшей частью разработки современных J2EE-приложений. В данной статье разработчик решений IBM Михаил Генкин рассказывает, как различные корпоративные информационные системы (Enterprise Information Systems, EIS) могут участвовать в транзакциях с использованием архитектуры J2EE Connector Architecture. В примере приложения электронной коммерции Михаил демонстрирует различные уровни поддержки транзакций, предоставляемые различными EIS-системами и адаптерами ресурсов, а также показывает, как эти факторы могут повлиять на дизайн приложения. В статье также приведены рекомендации Михаила по выбору правильной стратегии разграничения транзакций и настройки дескриптора развертывания EJB для вашего сценария корпоративной разработки.
Мир электронного бизнеса представляет собой быстро меняющуюся среду. Предприятиям необходимо интегрировать бизнес-логику и данные, доступные в существующих корпоративных информационных системах (таких как Customer Information Control System (CICS), Information Management System (IMS) или SAP), в новые приложения. Часто очень важные бизнес-транзакции пишутся на процедурных языках, таких как Cobol или C. Платформа J2EE™ имеет спецификацию, которая обеспечивает разработчиков стандартным интерфейсом для доступа к EIS-транзакциям и данным, - спецификацию J2EE Connector Architecture (JCA).
В данной статье я объясню, как соглашение по JCA-транзакциям помогает реализовать транзакционное поведение в приложениях для электронного бизнеса. В частности, вы узнаете о двух методах разграничения транзакций в JCA: распределенном разграничении транзакций и программном разграничении транзакций. Я рассмотрю преимущества и недостатки каждого из них и предложу рекомендации по выбору наиболее подходящего метода для вашего сценария разработки приложений. Затем я подробно рассмотрю пример корпоративного приложения, реализующего программное разграничение транзакций. Завершается статья рекомендациями по выбору и применению корректных настроек дескриптора развертывания EJB для вашего решения по разграничению транзакций.
Описанные в данной статье методики могут быть реализованы на любом сервере приложений, совместимом с J2EE 1.3 или выше, а также для обоих типов адаптеров ресурсов: JCA 1.0- и JCA 1.5-совместимых.
Обзор JCA-транзакций
Исследовать некоторые общие вопросы, связанные с JCA-транзакциями, поможет рабочий пример. В этом примере задачей является создание приложения электронной коммерции для компании, главной деятельностью которой является продажа потребителям произведенных товаров. Компания приняла решение расширить свое присутствие в Web и продавать свои товары более широкой аудитории. Web-сайт позволит любому потребителю, имеющему Web-браузер, зайти на домашнюю страницу компании, просмотреть каталог доступных продуктов, получить подробную информацию о ценах и наличии (а также описание) отдельных товаров, добавить товары в корзину покупок и, наконец, совершить покупку. Для иллюстрации необходимого транзакционного поведения я рассмотрю ситуацию, когда потребитель решает совершить покупку. На рисунке 1 показан дизайн приложения.
Рисунок 1. Обращение к EIS в вашем приложении электронной коммерции
Существующая IT-инфраструктура компании основана на двух корпоративных информационных системах. EIS1 - это мэйнфрейм, выполняющий Cobol-транзакции под управлением CICS. Выполняемые на данной системе транзакции реализуют бизнес-логику и данные, необходимые для заказа и управления взаимоотношениями с потребителями (Customer Relationship Management, CRM). EIS2 - это IMS-система, содержащая каталог описаний товаров, информацию о ценах и систему управления запасами. Для поддержки необходимых функций ваше J2EE-приложение должно быть способным обращаться к данным из обеих систем. Для совершения покупки необходимо выполнить следующие действия в качестве единицы работы (для одной транзакции):
- Получить текущую стоимость товара (EIS2).
- Ввести заказ потребителя в систему работы с заказами (EIS1).
- Выписать счет потребителю (EIS1).
- Обновить информацию о наличии товаров (EIS2).
Невыполнение шагов 2, 3 или 4 приведет к отмене всех предыдущих действий.
В данном примере Web-приложения клиент (JSP-страница на Web-уровне) ссылается и вызывает методы экземпляра сохраняющего состояние (statefull) сессионного EJB-компонента CustomerSession. CustomerSession используется для хранения содержимого корзины покупок, информации о товаре из каталога и информации о потребителе. Во время сеанса взаимодействия с конечным пользователем (см. рисунок 1) этот сессионный компонент аккумулирует и сохраняет выбранные товары и информацию о потребителе, необходимую для совершения покупки. Определенные в CustomerSession методы вызывают методы не сохраняющего состояния (stateless) сессионного EJB-компонента (с использованием компонента в качестве фасада) OrderService для активизации транзакций в EIS.
В данном дизайне не сохраняющий состояния сессионный компонент OrderService выступает в роли фасада для EIS1. Он определяет следующие методы:
-
OrderInfo addOrder(String customerId, ItemInfo itemInfo) использует общий клиентский интерфейс JCA (Common Client Interface, CCI) для активизации транзакции SHIPTO в EIS1. Эта транзакция ищет адрес доставки потребителю и подготавливает информацию, которую EIS затем передаст в отдел доставок. Возвращаемая структура OrderInfo содержит номер заказа (использующийся для отслеживания), стоимость доставки и информацию об адресе доставки.
-
BillingInfo billCustomer(String customerId, OrderInfo orderInfo) использует также JCA CCI для активизации транзакции BILLTO в EIS1. Эта транзакция ищет номер кредитной карты потребителя и списывает сумму заказа с его счета. Возвращаемая структура BillingInfo содержит суммарную стоимость для потребителя, включая плату за доставку, идентификационный номер заказа (использующийся для его отслеживания и аннулирования) и информацию о потребителе.
-
void cancelOrder(OrderInfo orderInfo) использует JCA CCI для активизации транзакции RMVORD, выполняющейся в EIS1 для отмены заказа.
Сессионный компонент CatalogService (см. рисунок 1) выступает в роли фасада для EIS2. Он определяет следующие методы:
-
double getItemPrice(String itemId) использует JCA CCI для активизации транзакции ITMPRICE в EIS2. Эта транзакция возвращает информацию о самой последней стоимости товара.
-
void updateStockInfo(String itemId, int numItems) использует JCA CCI для активизации транзакции UPDSTOCK в EIS2. Эта транзакция обновляет текущую информацию о наличии товара на основе его идентификатора. Входной параметр numItems может быть положительным или отрицательным.
Все эти пять методов и используемые EIS-транзакции выполняются как часть одной бизнес-транзакции. В следующем разделе вы узнаете, как это делается.
Уровни поддержки транзакций
Различные EIS-системы имеют различное транзакционное поведение. Некоторые из них не поддерживают транзакции вообще. Некоторые поддерживают транзакции, но не поддерживают протокол двухфазной фиксации транзакций (Two-Phase Commit, 2PC). Говорят, что они поддерживают локальные транзакции. Некоторые EIS-системы поддерживают локальные транзакции и 2PC. Говорят, что они поддерживают распределенные, или глобальные транзакции. Глобальные транзакции часто называют XA-транзакциями, поскольку они задействуют интерфейс XAResource.
В листинге 1 приведен сниппет из ra.xml для адаптера ресурсов CICSECI, который вы будете использовать для доступа к EIS1. Значение LocalTransaction элемента <transaction-support> указывает на то, что этот адаптер ресурсов поддерживает локальные транзакции, но не может принимать участие в глобальных транзакциях. Сессионный компонент OrderService использует этот адаптер ресурсов для доступа к CRM-транзакциям, выполняющимся в EIS1.
Листинг 1. Сниппет дескриптора ra.xml для адаптера ресурсов CICSECI
<!DOCTYPE connector PUBLIC "-//Sun Microsystems, Inc.//DTD Connector 1.0//EN"
"http://java.sun.com/dtd/connector_1_0.dtd">
<connector>
<display-name>ECIResourceAdapter</display-name>
<description>CICS J2EE ECI Resource Adapter</description>
<vendor-name>IBM</vendor-name>
<spec-version>1.0</spec-version>
<eis-type>CICS</eis-type>
<version>5.0.0 </version>
<license>
<description> </description>
<license-required>true</license-required>
</license>
<resourceadapter>
<managedconnectionfactory-class>
com.ibm.connector2.cics.ECIManagedConnectionFactory<
/managedconnectionfactory-class>
<connectionfactory-interface>
javax.resource.cci.ConnectionFactory</connectionfactory-interface>
<connectionfactory-impl-class>
com.ibm.connector2.cics.ECIConnectionFactory</connectionfactory-impl-class>
<connection-interface>javax.resource.cci.Connection</connection-interface>
<connection-impl-class>com.ibm.connector2.cics.ECIConnection</connection-impl-class>
<transaction-support>LocalTransaction</transaction-support>
|
В листинге 2 приведен сниппет из ra.xml для адаптера ресурсов IMS, который используется для доступа к EIS 2. В данном случае значение XATransaction элемента <transaction-support> указывает на то, что адаптер ресурсов поддерживает глобальные, или распределенные, транзакции.
Листинг 2. Сниппет дескриптора ra.xml для адаптера ресурсов IMS
<!DOCTYPE connector PUBLIC "-//Sun Microsystems, Inc.//DTD Connector 1.0//EN"
"http://java.sun.com/dtd/connector_1_0.dtd">
<connector>
<display-name>IMS Connector for Java</display-name>
<description>J2EE Connector Architecture resource adapter for IMS
accessing IMS transactions using IMS Connect </description>
<vendor-name>IBM Corporation</vendor-name>
<spec-version>1.0</spec-version>
<eis-type>IMS</eis-type>
<version>1.2.6</version>
<license>
<description>IMS Connector for Java is a component
of the IMS Connect product and as such
is not separately licensed. It requires an IMS Connect license.</description>
<license-required>true</license-required>
</license>
<resourceadapter>
<managedconnectionfactory-class>
com.ibm.connector2.ims.ico.IMSManagedConnectionFactory<
/managedconnectionfactory-class>
<connectionfactory-interface>
javax.resource.cci.ConnectionFactory</connectionfactory-interface>
<connectionfactory-impl-class>
com.ibm.connector2.ims.ico.IMSConnectionFactory</connectionfactory-impl-class>
<connection-interface>
javax.resource.cci.Connection</connection-interface>
<connection-impl-class>
com.ibm.connector2.ims.ico.IMSConnection</connection-impl-class>
<transaction-support>XATransaction</transaction-support>
<config-property>
|
 |
Поддержка JCA-транзакций
Два адаптера ресурсов, приведенных в листингах 1 и 2, отличаются своим уровнем поддержки транзакций. Однако в моем приложении для электронной коммерции необходимо координировать транзакцию в обеих этих системах. Для того чтобы справиться с подобной задачей, соглашение по JCA-транзакциям определяет набор разработанных интерфейсов, используя которые сервер приложений и EIS координируют транзакцию. EJB-контейнер общается с EIS через реализацию интерфейса ManagedConnection адаптера ресурсов, который представляет физическое соединение к этой EIS. Реализация ManagedConnection обычно использует проприетарную библиотеку для общения с EIS-системой при помощи понимаемого ею протокола.
Если адаптер ресурсов поддерживает локальные транзакции, он реализует также интерфейс javax.resource.spi.LocalTransaction. Когда EJB-контейнер должен активизировать транзакцию, он вызовет метод getLocalConnection() экземпляра реализации ManagedConnection. Он будет вызывать методы LocalTransactions begin(), commit() и rollback() для управления транзакцией.
Если адаптер ресурсов поддерживает XA или глобальные транзакции, он реализует также интерфейс javax.transaction.xa.XAResource. Каждый J2EE-совместимый сервер приложений имеет внутренний компонент, называемый Transaction Manager. Transaction Manager, на самом деле, является реализацией интерфейса javax.transaction.TransactionManager. Этот компонент помогает серверу приложений управлять границами транзакций. Transaction Manager использует метод getXAResource(), определенный интерфейсом ManagedConnection, для извлечения экземпляра XAResource. Transaction Manager использует методы, определенные интерфейсом XAResource, для координации протокола 2PC в нескольких менеджерах ресурсов.
Стратегии разграничения транзакций
JCA предоставляет два варианта управления транзакциями: программное разграничение транзакций или декларативное разграничение транзакций. Первый вариант требует использования Java Transaction API (JTA) для написания отдельного кода для каждой операции транзакции begin, commit и rollback. В этом случае код разграничения транзакций смешивается с кодом, реализующим бизнес-логику.
Второй подход, декларативное разграничение транзакций, не требует какого-либо дополнительного кодирования. При выборе этого подхода программа развертывания EJB настроит транзакционное поведение вместо вас путем изменения настроек дескриптора развертывания для компонента. EJB-контейнер будет затем использовать эти настройки дескриптора развертывания для автоматического выполнения операций транзакций begin, commit или rollback в определенное время. В данном случае бизнес-логика, реализованная в EJB-компоненте, остается переносимой, а транзакционное поведение можно настроить без перезаписи кода реализации компонента.
Для большинства случаев предпочтительным вариантом является декларативное разграничение транзакций. Программное разграничение обычно используется только тогда, когда гибкость декларативного разграничения транзакций недостаточна. В нашем примере две EIS-системы и соответствующие им адаптеры ресурсов имеют различные уровни поддержки транзакций. Только из-за этих факторов наилучшим способом гарантировать целостность и непротиворечивость данных является использование распределенных транзакций с протоколом 2PC.
Однако тот факт, что в моем примере распределенные транзакции поддерживает только EIS2, делает ситуацию еще более интересной. Для использования 2PC все системы, вовлеченные в транзакцию, должны поддерживать этот протокол. Следовательно я не могу использовать распределенную транзакцию, и должен буду полагаться на локальные транзакции, для того чтобы гарантировать непротиворечивые обновления в обеих системах. Мне придется группировать доступ к каждой EIS и вручную отменять изменения в одной EIS-системе при каких-либо нарушениях нормального хода работы во второй. Транзакции, которые отменяют ранее зафиксированные изменения, часто называют компенсирующими транзакциями. Я буду использовать программное разграничение транзакций, чтобы обеспечить более высокую гибкость для ручных обновлений.
Программное разграничение транзакций
В листинге 3 приведена реализация метода placeOrder приложения, определяемого сессионным компонентом CustomerSession. Реализация метода использует JTA API для запуска локальных транзакций, управляющих доступом к EIS1 и EIS2. В методе placeOrder сначала выполняется обращение к EIS2 для получения самой новой информации о стоимости. Такое обращение должно выполняться в рамках транзакции, хотя и является по своей природе обращением только по чтению. Причиной этого является то, что обновление информации о ценах в EIS2 может выполняться другими приложениями, и вы должны гарантировать, что данные о ценах являются не противоречивыми и зафиксированными. Обработка исключительных ситуаций и бизнес-логика были упрощены для краткости изложения.
Листинг 3. Метод placeOrder() EJB-компонента CustomerSession (с упрощенной для краткости обработкой исключительных ситуаций)
public OrderInfo placeOrder(ItemInfo itemInfo, CustomerInfo custInfo)
throws OrderException {
// Получить ссылку на UserTransaction.
// Инициализировать переменные.
BillingInfo billingInfo = null;
OrderInfo orderInfo = null;
double itemPrice = 0.0;
UserTransaction ut = null;
try
{
InitialContext ic = new InitialContext();
ut = (UserTransaction)ic.lookup("jta/UserTransaction");
}
catch (Exception e)
{
throw new OrderException(e.getMessage());
}
// Найти последнюю информацию о ценах в EIS2,
включая информацию о скидках для потребителя.
{
ut.begin();
itemPrice = catalogService.getItemPrice(itemInfo.getItemId(),
custInfo.getCustomerId());
ut.commit();
}
catch ( Exception e)
{
try
{
ut.rollback();
}
catch (Exception ex)
{
// Отмена транзакции выполнилась неудачно.
// Записать ошибку в журнал, ничего не восстанавливать.
}
// Передать исключительную ситуацию назад на UI-уровень,
пока компенсировать нечего.
throw new OrderException(e.getMessage());
}
itemInfo.setItemPrice(itemPrice);
// Обновить EIS1 - локальная транзакция
try
{
ut.begin();
billingInfo = orderService.billCustomer( custInfo.getId(), itemInfo );
orderInfo = orderService.addOrder( custInfo.getId(), itemInfo );
ut.commit();
}
catch ( Exception e)
{
// Пока ничего не компенсировать в EIS2.
try
{
ut.rollback();
}
catch (Exception ex)
{
// Отмена транзакции выполнилась неудачно.
// Дополнительно проверить и обработать ошибки, чтобы гарантировать
// непротиворечивость в EIS1.
}
throw new OrderException(e.getMessage());
}
// Обновить EIS2.
try
{
ut.begin();
catalogService.updateStockInfo(orderInfo.getItemId(),
orderInfo.getItemNumber());
ut.commit();
}
catch( Exception e )
{
// Отменить оригинальную транзакцию в EIS2.
try
{
ut.rollback();
}
catch (Exception ex)
{
// Отмена транзакции выполнилась неудачно. Записать в журнал.
// Дополнительные проверки и обработка ошибок.
// Пока не выходить из метода.
}
// Компенсировать изменения в EIS1 как одну однофазную транзакцию.
try
{
ut.begin();
orderService.cancelOrder( orderInfo );
orderService.cancelCharge( billingInfo );
ut.commit();
}
catch ( Exception ex)
{
// Компенсация выполнилась неудачно, записать ошибку в журнал
try
{
ut.rollback();
}
catch (Exception exx)
{
// Отмена транзакции выполнилась неудачно
// Записать ошибку в журнал
}
throw new OrderException(ex.getMessage());
}
// Передать исключительную ситуацию обратно на UI-уровень
throw new OrderException(e.getMessage());
}
return orderInfo;
}
|
Следующим действием является выполнение двух обновлений в EIS1: одно в системе обработки заказов, а другое - в платежной системе. Можно выполнить эти обновления в рамках одной локальной транзакции. При неудачном завершении одного из обновлений можно передать исключительную ситуацию на UI-уровень и выйти из метода без попытки обновить EIS2. UI-уровень должен будет уведомить пользователя об ошибке транзакции и выдать запрос о том, что делать с этой ситуацией дальше. Пользователь может выбрать повтор действия или выход из приложения. Поскольку обе эти операции выполняются в одной и той же транзакции, а предыдущий доступ к EIS2 является доступом только по чтению, на данном этапе не требуется каких-либо компенсирующих действий.
Последним действием является обновление списка доступных товаров в EIS2. Опять это надо сделать в рамках локальной транзакции, однако данная транзакция отличается от уже завершенной EIS1-транзакции. Поскольку здесь используется программное разграничение транзакций, ошибка в обновлении EIS2 приведет к необходимости отмены зафиксированных изменений в EIS1. Вот почему блок catch содержит вызовы EIS1-транзакций, отменяющих обновления в системе обработки заказов и платежной системе.
Важно отметить, что подход с программным разграничением транзакций не является хорошей заменой распределенным транзакциям с 2PC. Если неудачно завершатся сами компенсирующие транзакции, система останется в противоречивом состоянии. В реальных приложениях понадобится дополнительная обработка исключительных ситуаций для работы в подобного рода ситуациях. Например, в случае неудачного завершения компенсирующей транзакции можно было бы передать уведомление системному администратору или использовать технологию обмена сообщениями для попытки выполнить эти транзакции в другое время.
Настройки дескриптора развертывания EJB
В основанном на EJB-технологии решении программа развертывания EJB должна указать серверу приложений способ работы с разграничением транзакций путем настройки дескриптора развертывания EJB. Первым шагом для выбора корректных настроек дескриптора развертывания для вашего приложения является оценка его требований. Вот что мы знаем о примере JCA-реализации:
- Дескриптор развертывания для EJB-компонента
CustomerSession должен указывать, что используется программное (то есть управляемое компонентом) разграничение транзакций (TX_BEAN_MANAGED).
- Дескрипторы развертывания для сессионных компонентов
OrderService и CatalogService должны использовать декларативное (то есть управляемое контейнером) разграничение транзакций, и методы в этих компонентах всегда должны выполняться в контексте транзакции.
- Сессионные компоненты
OrderService и CatalogService обеспечивают доступ к использующимся EIS-транзакциям. Методы этих компонентов вызываются сессионным компонентом CustomerSession, реализующим логику процесса вне вашего приложения, а также другими ориентированными на процесс компонентами.
- Компонент
CustomerSession должен начинать транзакцию до вызова методов OrderService, потому что транзакция выполнит несколько операций в EIS1. Поскольку каждая из двух операций в EIS2 может выполняться как независимая транзакция (и обе могут не быть частью глобальной транзакции, охватывающей все четыре операции), для вызова методов CatalogService можно использовать как программное, так и декларативное разграничение транзакций (обратите внимание на то, что я уже сделал выбор и разрешил компоненту CustomerSession управлять границами транзакций для всех операций).
Исходя из этих требований, можно использовать настройку дескриптора развертывания TX_REQUIRED для компонентов CatalogService и OrderService. Эта настройка будет гарантировать, что методы компонентов могут подключаться к уже выполняющейся транзакции или начать новую (при необходимости). Обратите внимание на то, что при использовании TX_REQUIRED, если вызывающий код не начал транзакцию, каждый вызов, включая вызовы к EIS1, будет выполняться как отдельная транзакция. Это не то, что нам нужно.
Альтернативным подходом могло бы быть требование, чтобы каждый компонент (например, CustomerSession), реализующий логику процесса, выполнял разграничение транзакции. Этот подход, который мог бы быть реализован при помощи настройки дескриптора развертывания TX_MANDATORY для сессионных компонентов OrderService и CatalogService, гарантировал бы желаемое транзакционное поведение для приложения. При выборе данного подхода вызывающий компонент должен был бы начинать транзакцию до вызова методов фасада EIS или генерировать исключительную ситуацию. Единственным недостатком данного подхода является требование, чтобы компоненты, которым нужны только транзакции, состоящие из одного метода, несли ответственность за управление границами транзакций.
Указание уровня изоляции транзакций
Спецификация J2EE определяет атрибут дескриптора развертывания, указывающий уровень изоляции транзакций для данного EJB-метода. Например, программа развертывания EJB могла бы настроить уровень изоляции транзакций для метода getItemPrice() сессионного компонента CatalogService на выполнение с уровнем изоляции TRANSACTION_READ_COMMITTED, чтобы гарантировать чтение во время транзакции только зафиксированных данных о стоимости товаров. Изменяя уровень изоляции, J2EE-разработчик может балансировать между целостностью данных и ограничениями производительности при выполнении настройки приложения.
Однако различные EIS-системы отличаются по своим транзакционным возможностям и будут по-разному реагировать на настройки уровня изоляции транзакций. В этом случае изменения настроек изоляции транзакций для фасадов EIS будут иметь небольшие различия, поскольку протоколы взаимодействия ECI и XCF не будут передавать эту информацию в системы хранения данных. COBOL-транзакции, выполняющиеся в данных системах, будут решать задачи изоляции транзакций с использованием программных методик, специфичных для этих платформ.
Выбор решения
Вообще-то, для определения того, как данная EIS будет реагировать на настройки изоляции транзакций, необходимо обратиться к документации по этой EIS и по адаптеру ресурсов, используемому для подключения к ней. Хотя используемые в примере адаптеры ресурсов не реагируют на изменения настроек уровня изоляции транзакций J2EE, работа некоторых EIS-систем, построенных на реляционных базах данных, может зависеть от них. Необходимо в деталях понимать поведение конкретной EIS-системы при таких изменениях, поскольку от этого могут существенно зависеть показатели производительности самой EIS-системы и вашего приложения. В наихудшем сценарии может нарушиться целостность данных. Разработчики J2EE-проектов должны консультироваться с администраторами EIS, для того чтобы гарантировать корректные политики изоляции транзакций.
В заключение
Спецификация Java Connector Architecture предоставляет J2EE-разработчикам удобное решение для создания транзакционных J2EE-приложений, работающих с традиционными системами. JCA позволяет интегрировать существующие EIS-системы, обеспечивая в то же время поддержку корректных транзакционных семантик, необходимых для электронной коммерции.
Главная проблема, которую приходится решать, связана с тем, что различные адаптеры ресурсов поддерживают различные уровни поддержки транзакций. Во многих случаях может оказаться невозможным использование имеющегося менеджера транзакций для координации распределенных транзакций в системах. В некоторых случаях распределенные транзакции вообще нежелательны из-за влияния на производительность протокола двухфазной фиксации транзакции.
В таких ситуациях, возможно, понадобится реализация логики компенсации транзакций и программное разграничение транзакций. Этот подход тоже имеет свои недостатки. Компенсирующие транзакции и сами могут выполниться неудачно, что приведет к нарушению целостности системы.
Еще одной ловушкой, которой нужно опасаться, является тот факт, что спецификация JCA не описывает, как адаптер ресурсов должен обрабатывать уровни изоляции транзакций EJB. Некоторые адаптеры ресурсов просто игнорируют эти настройки из-за того, что коммуникационный протокол EIS-системы не передает эту информацию на сервер данных, или из-за того, что модель транзакций целевой EIS-системы не предоставляет какое-либо эквивалентное понятие. В других случаях изменения в уровнях изоляции транзакций J2EE может значительно повлиять на производительность EIS. Для определения точного поведения вы должны тщательно изучить документацию по адаптеру ресурсов и связаться с производителем, если данный аспект не описан достаточно подробно.
Ресурсы
- Примите участие в обсуждении материала на форуме.
- Оригинал статьи "Understanding JCA transactions" (EN).
- В учебном руководстве Вили Фаррелла (Willy Farrell) "Введение в J2EE Connector Architecture" (EN) рассмотрены основы работы с JCA.
- Статья "Разработка приложений с использованием инструментальных средств, основанных на JCA" (EN) (developerWorks, январь 2002) знакомит с практическими аспектами J2EE Connector Architecture и использованием основанных на JCA инструментальных средств от IBM для создания, тестирования, развертывания и выполнения J2EE EJB-приложений (выдержки из книги "J2EE Connector Architecture и интеграция корпоративных приложений" (EN), Рахул Шарма (Rahul Sharma), Бет Стеарнз (Beth Stearns) и Тони Нг (Tony Ng); Addison-Wesley, 2001).
- В статье "Создание JCA-совместимых адаптеров ресурсов с использованием WebSphere Studio Application Developer" (EN) (developerWorks, август 2003) рассматривается процесс написания вашего собственного JCA-совместимого адаптера ресурсов.
- "Для новичков и ветеранов" (EN) (developerWorks, июнь 2002) - руководство по интеграции традиционных CICS-транзакций с использованием основанных на JCA инструментальных программ от IBM.
-
Спецификация J2EE - полный справочник по модели программирования EJB.
- "Начало работы с технологией EJB" (EN) (developerWorks, апрель 2003) - всеобъемлющее руководство по основам EJB-программирования и среде J2EE.
- Дополнительная информация по спецификации JCA приведена на домашней странице JCA.(EN)
- В разделе Java-технологий на developerWorks размещены статьи по всем аспектам Java-программирования.
-
Книги по данной и другим техническим темам.(EN)
- На странице учебных руководств в разделе Java-технологий на developerWorks размещен полный список руководств по Java.
Об авторе | | |
Михаил Генкин (Mikhail Genkin) - разработчик решений в IBM Integrated Services and Support for WebSphere. Он помогает клиентам IBM создавать решения по интеграции деятельности. Участвовал в разработке нескольких версий Visual Age for Java, Enterprise Edition, WebSphere Application Server, Enterprise Edition и WebSphere Application Developer, Integration Edition. |
Выскажите мнение об этой странице
| |
