|
Модераторы: LSD, AntonSaburov |
|
ekr |
|
|||
...и это пройдет... Профиль Группа: Участник Сообщений: 359 Регистрация: 6.5.2007 Где: Moscow, RU Репутация: 12 Всего: 19 |
Выложил вторую часть статьи на блог.
Доступ к внешним системам и механизм глобальных транзакций на платформе 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 на примере чуть попозже, а пока рассмотрим простейшее решение. Итак, нам надо в рамках одной транзакции изменить данные в двух различных СУБД. Все, что у нас есть - это инструмент локальных транзакций каждой из них. Напрашивается то самое решение в лоб:
Правильным решением будет использование как раз того самого 2PC. Идея этого алгоритма заключается в том, что локальные транзакции не завершаются до тех пор, пока на всех источниках не пройдут обновления. Это позволяет всем локальным транзакциям завершится (хоть и чуть попозже) одинаково. Если все прошло нормально - то подтверждением, если хоть одно обновление прошло с ошибкой - то откатом. Схема получается следующая:
Эта идея 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:
Здесь уместно отступление, связанное с неоднозначностью интерпретации спецификации. Дело в том, что спецификация регламентирует два интерфейсных к TM объекта: первый, реализующих уже знакомый нам интерфейс javax.transaction.UserTransaction и второй, реализующий javax.transaction.TransactionManager. Как гласит спецификация, UserTransaction является интерфейсом к TM для разработчика, а TransactionManager является интерфейсом к TM для самого контейнера и его объектов (например, для EJBObject-ов - сгенерированных контейнером объектов-перехватчиков, стоящих перед EJB instances, экземплярами бинов). Но спецификация не говорит о том, нужно ли делать доступным объект TransactionManager разработчику. Поэтому доступность TransactionManager-а разработчику определяет каждый производитель контейнера по-своему. Интерфейс TransactionManager предоставляет более широкий API, нежели UserTransaction: рис. 11 Как разработчик получает доступ к транзакционному контексту - UserTransaction? Разработчик из своих приложений получает доступ к UserTransaction в зависимости от типа приложения:
В связи с этим были возможны проблемы с переносимостью приложений между j2ee-серверами (это не касается session ejb, где bmt-компонент получает транзакционный контекст из ejb context или как dependency injection; и не касается session cmt и entity ejb, где вообще нет процедурного доступа к транзакционному контексту, кроме метода setRollbackOnly). Но на данный момент Sun Microsystems явно рекомендует вендорам следующий путь: java:comp/UserTransaction Каркас приложения, использующего глобальные транзакции Давайте вспомним сценарий работы приложения с глобальными транзакциями:
рис. 12
рис. 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 завершать? А все дело в том, что:
Здесь следует сделать небольшое отступление по поводу идентификаторов локальных транзакций. Дело в том, что прикладной разработчик, работая с локальными транзакциями, по сути, не нуждается в их идентификаторах. Для него важно то, что транзакция привязывается к соединению (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, но и подготовить соответствующую инфраструктуру средствами сервера.
Заключение Глобальные транзакции - очень мощный и гибкий инструмент, а в ряде случаев просто незаменимый. Но пользоваться этим инстументом надо с умом, т.к. он требует от разработчика и администратора повышенной квалификации. К тому же, глобальные транзакции очень ресурсоемкое удовольствие, поэтому не следует ими пользоваться в ситуациях, где можно обойтись обычными локальными транзакциями. Темы, не вошедшие в рассмотрение Статья не может, к сожалению, охватить все аспекты, поэтому ряд тем не вошло в рассмотрение:
Это сообщение отредактировал(а) ekr - 17.10.2007, 17:33 |
|||
|
||||
batigoal |
|
|||
Нелетучий Мыш Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: 16 Всего: 151 |
ekr, весьма интересные статьи.
-------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
ekr |
|
|||
...и это пройдет... Профиль Группа: Участник Сообщений: 359 Регистрация: 6.5.2007 Где: Moscow, RU Репутация: 12 Всего: 19 |
спасибо )
если будут замечания и добавления - буду только рад ) |
|||
|
||||
ekr |
|
|||
...и это пройдет... Профиль Группа: Участник Сообщений: 359 Регистрация: 6.5.2007 Где: Moscow, RU Репутация: 12 Всего: 19 |
перенес статью на форум
|
|||
|
||||
sith |
|
|||
Опытный Профиль Группа: Участник Сообщений: 537 Регистрация: 11.2.2007 Репутация: нет Всего: 1 |
ну а я все таки продолжу с моим старым вопросом-примером
... есть файловый ресурс - папки, файлы, есть к нему БД которая хранит всебе различного рода свойства к папкам и файлам и файлового ресурса... и так если я добавляю файл копирую в ресурс файл то я паралельно с файлом должен записать его свойства в БД... ну и так далее... ... как сюда прекрутить глобальные транзакции и JTA -------------------- Там где ты ставишь глупые смайлики, я вбиваю восклицания знаки!!! |
|||
|
||||
ekr |
|
|||
...и это пройдет... Профиль Группа: Участник Сообщений: 359 Регистрация: 6.5.2007 Где: Moscow, RU Репутация: 12 Всего: 19 |
Продолжим ответ ) Необходимо написать (или взять существующий) j2ca-ный адаптер к файловой системе. Он должен уметь участвовать в распределенных транзакциях, т.е. реализовывать XA. Соответственно, в бизнес-логике глобальная транзакция JTA будет выглядеть так:
Как я понял, у тебя основная проблема, где взять такой XA-адаптер файловой системы. Здесь помочь, к сожалению, не могу, но более чем уверен, что такие есть. |
|||
|
||||
Правила форума "Java" | |
|
Если Вам помогли, и атмосфера форума Вам понравилась, то заходите к нам чаще! С уважением, LSD, AntonSaburov, powerOn, tux. |
1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Java EE (J2EE) и Spring | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |