Доступ к внешним системам и механизм глобальных транзакций на платформе J2EE: часть 2

Disclaimer
Это продолжение статьи, первую часть Вы можете найти здесь.

Понятие транзакции
Транзакция - группа операций над данными, которая выполняются или вся, или не выполняется вообще. Более подробно о понятиях и базовых свойствах транзакций можно почитать, например, в википедии. Основная задача транзакции - обеспечить целостность данных. В практически любой, даже самой простой информационной системе, можно встретить использование разработчиками локальных транзакций на источнике данных.
Еще один важный момент, который стоит напомнить, - транзакция имеет границы (boundaries), т.е. начало и завершение. Завершиться транзакция может подтверждением (commit) или откатом (rollback).

Локальные транзакции
Локальная транзакция - это транзакция на одном источнике данных.

В качестве хранилища данных в большинстве случаев мы будем рассматривать СУБД, но следует помнить, что это может быть так же и внешняя корпоративная система (EIS), и JMS-ресурс.
Следует обратить внимание на ключевое слово - локальная. Для разработчика это значит, что он может ограничивать транзакцию (определять transaction boundaries) в бизнес-логике, когда в ней происходят чтение/модификация данных из одного источника.
Что же такое источник данных? На бытовом уровне вроде понятно - это СУБД или JMS destination или EIS. Но потребуется существенное уточнение, когда мы перейдем к конкретному API. Ведь мы можем получить несколько соединений с одной СУБД через JDBC API? Что в этом случае понимать под источником данных? СУБД или соединение? К тому же, в большинстве случаев будет использоваться пул соединений, и что тогда считать источником данных: DataSource, пул или само соединение?
Для ответа на этот вопрос следует вспомнить рис. 5. Из его анализа вытекает первый тезис : источник данных - это Resource Manager. Разработчик не работает с внутренней структурой RM, он работает из бизнес-логики j2ee-приложений с соединениями (connections). Так что можно утвердить второй тезис: для разработчика интерфейсом к источнику данных является соединение. В зависимости от типа RM это может быть JDBC connection, JMS connection или J2CA Connection.
Так же уместно взгянуть на рис. 6 для того, чтобы вспомнить, откуда разработчик получает эти соединения. Получение соединений происходит из фабрик соединений нужного типа.

Здесь следует отметить лингвистический нюанс - в общем случае фабрики так и именуются: JMS Connection Factory, J2CA Connection Factory. Особняком стоит JDBC API, где фабрика называется DataSource. Дословный перевод - "источник данных" - означает немного не то, что под этим термином подразумевается в статье (весь RM). Поэтому в статье я темин DataSource буду употреблять, не переводя.
После того, интерфейс к источнику данных - соединение - получено, разработчик может пользоваться управлять локальными транзакциями. Соответственно, чтобы разработчик мог воспользоваться этим транзакционным функционалом, выбранная технология должна предоставить его в своем API. Так что и JDBC, и JMS, и J2CA предоставляют набор методов для работы с локальными транзакциями.
Вроде, все чудесно ;-) У нас есть API локальных транзакций источника, разработчик теперь может в своей бизнес-логике им пользоваться, тем самым обеспечивая целостность данных. Но с ростом сложности информационных систем возникает проблема - источников данных становится несколько, причем, зачастую, разных типов. В качестве примера можно рассмотреть работу гипотетической ИС по приему нового работника в штат компании: нужно данные о нем прописать во внутренней БД по учету персонала, во внешней БД головной компании, в PeopleSoft и 1С:Бухгалтерии (внешние КИС). При этом все изменения во всех хранилищах должны пройти целостно, т.е. если где-то в одном из них случилась ошибка, то нигде в остальных информация не должна появиться.
Вот пример глобальной транзакции - налицо все свойства локальной, но эта глобальная транзакция охватывает изменения на нескольких источниках данных.

Глобальные транзакции, 2PC
Теперь следует немного подняться с уровня API на уровень алгоритмов и задуматься, как технически реализовать идею глобальных транзакций. Что у нас есть, так это инструмент локальных транзакций, отлаженный, работающий, реализованный в большинстве RM.
Основная идея, используемая для реализации глобальных транзакций - это 2PC, 2 Phase Commit Protocol - протокол двухфазного подтверждения транзакций. Эта идея довольно проста: глобальная транзакция состоит из двух этапов (фаз): подготовка и завершение.
Давайте рассмотрим 2PC на примере чуть попозже, а пока рассмотрим простейшее решение. Итак, нам надо в рамках одной транзакции изменить данные в двух различных СУБД. Все, что у нас есть - это инструмент локальных транзакций каждой из них. Напрашивается то самое решение в лоб:

1. начало локальной транзакции на первом источнике (Тр1)
   
2. обновление данных на первом источнике
   
3. завершение Тр1
   
4. начало локальной транзакции на втором источнике (Тр2)
   
5. обновление данных на втором источнике
   
6. завершение Тр2

Так вот - это неправильное решение. Дело в том, что локальные Тр1 и Тр2 сами по себе целостны, но в совокупности целостности не обеспечивают. Представим, что первое обновление прошло удачно, а это значит, что Тр1 завершится подтверждением. А при втором обновлении может случиться ошибка (нет такой записи, дублицирование PK или что-то еще), что приведет к завершению Тр2 откатом. В итоге имеем нарушение целостности данных. Все плачут :-( А все потому, что до самой последней модификации мы не знаем, будут ли ошибки, поэтому смело подтверждать первую транзакцию не стоит, возможно, в конце все приведет к откату.

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

1. начало локальной транзакции на первом источнике (Тр1)
   
2. обновление данных на первом источнике
   
3. начало локальной транзакции на втором источнике (Тр2)
   
4. обновление данных на втором источнике
   
5. если ошибок нигде не было, то (а) подтверждение Тр1 и (б) подтверждение Тр2
   
6. если были ошибки, то (а) откат Тр1 и (б) откат Тр2
   

Соответственно, этапы 1-4 называются фазой подготовки, а этапы 5 и 6 - фазой завершения глобальной транзакции. В зависимости от наличия ошибок обновления глобальная транзакция, как и локальная, может завершиться подтверждением или откатом.

Эта идея 2PC может быть реализована на любой платформе и любыми средствами, главное, чтобы был работающий механизм локальных транзакций. Но тогда получается, что разработчик, желающий использовать распределенные транзакции, должен мучится и кодировать 2PC-алгоритм в своей бизнес-логике?
Не обязательно. Как раз для того, чтобы снять с прикладного разработчика задачу реализации в коде таких алгоритмов, существует класс программных продуктов - Transaction Monitors.

Transaction Monitor и JTA
TM (Transaction Manager или Transaction Monitor) - специальное ПО, которое берет на себя задачу реализации алгоритма 2PC, снимая её с прикладного разработчика. Существует множество реализаций от разных производителей, например Microsoft Transaction Server или BEA Tuxedo. Но в случае платформы j2ee не надо докупать отдельный продукт, TM является частью сервера приложений. Естественно, что реализации TM различных производителей j2ee-серверов различаются рядом характеристик, но мониторы всех серверов доступны прикладному разработчику через унифицированный API - JTA (Java Transaction API), регламентированный JSR-ом за номером 907.
При использовании TM в j2ee-сервере разработчику достаточно лишь посылать сигналы монитору о старте и подтверждении/откате глобальной транзакции, а сигналы локальных подтверждений/откатов монитор разошлет RM-ам самостоятельно.
Таким образом, бизнес-логика наших j2ee-приложений трансформируется (и вместо самостоятельной реализации 2PC доверяем это транзакционному монитору):

1. посылка сигнала TM о начале глобльной транзакции ГТр
   
2. обновление данных на первом источнике, обновление данных на втором источнике
   
3. если ошибок нигде не было, то подтверждение ГТр, если были ошибки, то откат ГТр
   
4. TM сам разошлет сигналы локальных подтверждений или откатов всем задействованным RM

рис. 7

Этапы 1, 2 - фаза подготовки; этапы 3, 4 - фаза завершения глобальной транзакции.

Что же из себя представляет Java Transaction API?
JTA представляет из себя набор классов исключений и интерфейсов, с помощью которых разработчик может управлять глобальными транзакциями:

рис. 8

Ключевым интерфейсом для прикладного разработчика является javax.transaction.UserTransaction. J2EE-сервер предоставляет разработчику объект, реализующий этот интерфейс, и с его помощью программист может управлять глобальными транзакциями. UserTransaction является, по сути, интерфейсом разработчика к TM и часто этот объект, предоставляемый контейнером, называют транзакционным контекстом, или просто UserTransaction - по имени интерфейса.
Давайте рассмотрим методы транзакционного контекста:

рис. 9

Методы его self-descriptive, я лишь приведу перевод выдержки из спецификации JTA:

• public void begin() throws NotSupportedException, SystemException
  Создает новую глобальную транзакцию и ассоциирует её с текущим потоком - тредом.
  
• public void commit() throws RollbackException, HeuristicMixedException, HeuristicRollbackException, SecurityException, IllegalStateException, SystemException
  Завершает текущую транзакцию (ассоциированную с текущим потоком) подтверждением. После выполнения этого метода текущий поток более не ассоциирован ни с какой транзакцией.
• public int getStatus() throws SystemException
  Возвращает статус текущей транзакции. Специально для анализа статуса предназначен интерфейс javax.transaction.Status, у которого определено 10 констант с предопределенными именами статусов транзакции:
  
  
  рис. 10
  

  
  Подробное обсуждение статусов транзакции выходит за рамки данной статьи.
  
• public void rollback() throws IllegalStateException, SecurityException, SystemException
  Завершает текущую транзакцию откатом. После выполнения этого метода текущий поток более не ассоциирован ни с какой транзакцией.
• public void setRollbackOnly() throws IllegalStateException, SystemException
  Помечает текущую транзакцию таким образом, что она в дальнейшем может завершиться только откатом.
• public void setTransactionTimeout(int seconds) throws SystemException
  Устанавливает таймаут текущей транзакции. Если из приложения не вызывался этот метод, то таймаут устанавливается в значение по умолчанию (скорее всего, выставленное в конфигурации сервера).

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

Здесь уместно отступление, связанное с неоднозначностью интерпретации спецификации. Дело в том, что спецификация регламентирует два интерфейсных к TM объекта: первый, реализующих уже знакомый нам интерфейс javax.transaction.UserTransaction и второй, реализующий javax.transaction.TransactionManager.
Как гласит спецификация, UserTransaction является интерфейсом к TM для разработчика, а TransactionManager является интерфейсом к TM для самого контейнера и его объектов (например, для EJBObject-ов - сгенерированных контейнером объектов-перехватчиков, стоящих перед EJB instances, экземплярами бинов).
Но спецификация не говорит о том, нужно ли делать доступным объект TransactionManager разработчику. Поэтому доступность TransactionManager-а разработчику определяет каждый производитель контейнера по-своему.
Интерфейс TransactionManager предоставляет более широкий API, нежели UserTransaction:

рис. 11

Как разработчик получает доступ к транзакционному контексту - UserTransaction?
Разработчик из своих приложений получает доступ к UserTransaction в зависимости от типа приложения:

• Удаленные клиенты - из сервиса именования (jndi-дерева)
• Веб-компоненты (сервлеты, jsp, ect.) - так же из из сервиса именования
  
• Session EJB - в зависимости от типа (BMT или CMT) и версии (2.x или 3)- из сервиса именования, из ejb-контекста или как dependency injection

На этом месте возникает резонный вопрос - а как разработчик узнает jndi-путь (имя контекста), по которому доступен UserTransaction? Дело в том, что спецификация JTA обязывает производителя сервера предоставить доступ разработчику к транзакционному контексту, но до определенной версии j2ee явно не регламентировала его jndi-адрес. Так что различные вендоры использовали различные пути, а в приведенном ниже примере (рис. 12 и 13) проиллюстрировано j2ee-приложение для BEA WebLogic 8, где имя контекста UserTransaction было javax.transaction.UserTransaction - по имени интерфейса.
В связи с этим были возможны проблемы с переносимостью приложений между j2ee-серверами (это не касается session ejb, где bmt-компонент получает транзакционный контекст из ejb context или как dependency injection; и не касается session cmt и entity ejb, где вообще нет процедурного доступа к транзакционному контексту, кроме метода setRollbackOnly).
Но на данный момент Sun Microsystems явно рекомендует вендорам следующий путь: java:comp/UserTransaction

Каркас приложения, использующего глобальные транзакции
Давайте вспомним сценарий работы приложения с глобальными транзакциями:

• посылка сигнала TM о начале глобльной транзакции ГТр
  
• обновление данных на первом источнике, обновление данных на втором источнике
  
• если ошибок нигде не было, то подтверждение ГТр, если были ошибки, то откат ГТр
  
• TM сам разошлет сигналы локальных подтверждений или откатов всем задействованным RM

Соответствующий код приложения будет выглядеть примерно следующим образом:

рис. 12

• первый этап - получение транзакционного контекста из сервиса именования (jndi-дерева)
• второй этап - посылка сигнала о начале глобальной транзакции
• третий этап - посылка сигнала о подтверждении глобальной транзакции

Но это не полный пример, так как надо учитывать необходимость отката транзакции в случае ошибок (которые в нашем приложении проявятся как exceptions).

рис. 13

Изменения данных, охваченные транзакцией (begin/commit) на рис. 12 и 13, будут целостными - "все или ни одного". Таким образом разработчик через интерфейс к Transaction Monitor-у javax.transaction.UserTransaction способен управлять глобальными транзакциями.

Расширенные вопросы работы TM, XID, интерфейс XA
Как мы увидели, TM берет на себя целый спектр задач. Как же этот сервис контейнера реализует их? Ведь следует помнить, что сервисом пользуется одновременно множество j2ee-приложений, причем те же самые сервлеты, к тому же, выполняются в многопоточном режиме. Как же один и тот же TM понимает, на какие именно RM посылать сигналы завершения локальных транзакций, какие именно RM были вовлечены в текущую транзакцию, если этих транзакций в системе протекает множество, и каждая из них вовлекает различные TM?
Давайте взглянем на функционирование TM более подробно. При старте глобальной транзакции ей присваивается уникальный идентификатор - XID, и этот XID генерируется автоматически TM-ом. Как только бизнес-логика, выполняющаяся в рамках глобальной транзакции, модифицирует данные в каком-либо Resource Manager, TM автоматически связывает идентификатор локальной транзакции этого RM с идентификатором глобальной транзакции, XID-ом. Таким образом, TM постоянно ведет так называемый TLOG (transaction log), в котором меппятся XID-ы на идентификаторы локальных транзакций, которые охвачены этим XID.
Давайте более подробно рассмотрим этот процесс:

рис. 14

В рамках j2ee-контейнера выполняется бизнес-логика (метод сервлета, ejb или простого java-класса). Метод стартует глобальную транзакцию (этап 1), при этом TM-ом создается идентификатор транзакции - XID.
Далее из бизнес-логики происходит модификация данных через resource managers (этапы 2 и 3):

рис. 15

После этого в логике присходит анализ исключений, и в зависимости от их наличия глобальная транзакция завершается или подтверждением, или откатом (этап 4):

рис. 16

Далее на второй фазе (2PC) глобальной транзакции TM рассылает задействованным в ней RM-ам сигнал локального подтверждения или отката (этап 5):

рис. 17

В принципе, этот процесс мы рассмотрели в предыдущем разделе, и пришло время ответить на вопрос: каким же образом TM, которому поступает множество сигналов от различных приложений, знает, каким RM посылать сигналы и какие именно локальные транзакции этих RM завершать?
А все дело в волшебных пузырьках в том, что:

• Во-первых, XID привязывается к треду (см. так же пояснения к рис. 9). То есть, даже в случае веб-приложений, где метод одного сервлета может выполняться в многопоточном режиме, TM всегда четко знает, какой XID завершать, исходя из того треда, который вызывает метод rolback или commit.
  Так же привязка XID к треду дает чудесный эффект: мы мыжем иметь довольно глубокий стек вызовов, и все эти вызовы будут проходить в рамках одной и той же транзакции. То есть, можно в сервлете начать глобальную транзакцию, вызвать из него метод класса (POJO), затем метод ejb, затем модифицировать данные, и все эти изменения пройдут как одна транзакция. При этом тот ejb может так же вызывать другие ejb и методы POJO с тем же эффектом. XID привязывается к треду, поэтому куда бы тред ни зашел, вся эта логика выполнится как одна транзакция.
  
  
  рис. 18
  
  
• Во-вторых, TM ведет транзакционный лог (TLOG), где скурпулезно записывает для каждого XID в какой RM он вошел и идентификатор этой локальной транзакции.

рис. 19

Именно эти два фактора позволяют TM-у четко определять, какие именно локальные транзакции на каких RM необходимо завершать, когда поступает сигнал завершения глобальной транзакции.

Здесь следует сделать небольшое отступление по поводу идентификаторов локальных транзакций. Дело в том, что прикладной разработчик, работая с локальными транзакциями, по сути, не нуждается в их идентификаторах. Для него важно то, что транзакция привязывается к соединению (connection). Поэтому нужно, чтобы на второй фазе глобальной транзакции фабрика соединений RM-а выдала из пула то же самое соединение, что и на предыдущем этапе модификации данных. Соответственно, на этапе конфигурации фабрики необходимо указывать, что это фабрика, способная участвовать в глобальный транзакциях административными средствами сервера. Такая фабрика в том числе будет отвечать за выдачу одинаковых connections из пула в обеих фазах глобальной транзакции.

Интерфейс XA
Далее возникает следующая проблема. Не стоит забывать, что RM-ы могут быть разной природы, т.е. реализовывать различные интерфейсы: JDBC, JMS, J2CA и другие. Соответственно, на второй фазе глобальной транзакции, когда TM-у надо будет рассылать сигналы локальных завершений, ему надо будет это делать через специфичный для RM-а API (см. этап 5 на рис. 17). А это крайне серьезно усложняет TM, ведь популярных API RM-ов немало, и неизвестно, какие появятся в будешем. На выходе имеем излишнее усложнение и проблемы с поддержкой. Следовательно, необходимо абстрагировать TM от API RM-ов.
Как раз для этого в свое время был разработан интерфейс XA (eXtended Architecture). Его цель - обеспечить унифицированный, общий для всех типов RM интерфейс управления локальными транзакциями. При использовании XA-драйверов разработчик пользуется технологическим API (jms, jdbc), а TM пользуется интерфейсом XA.

рис. 20

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

1. Следует использовать XA-драйвера при настройке RM
   
2. В настройках фабрики соединений указывать, что она Global Transactional

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

Темы, не вошедшие в рассмотрение
Статья не может, к сожалению, охватить все аспекты, поэтому ряд тем не вошло в рассмотрение:

• История глобальных транзакций - OMG, X/OPEN, CORBA
• JTS
  
• Эмуляция XA в не-XA-драйверах
• Heuristics
• Distributed vs Global transactions
• Проблемы совместного использования локальных и глобальных транзакций

Если эти темы вызовут интерес, я раскрою их более подробно в следующих статьях.

P.S. C первым снегом Вас, коллеги! )))