Реальный пиарJavaScriptПишем на JavaScript → Некоторые способы реализации механизма распределенной транзакции

Некоторые способы реализации механизма распределенной транзакции

Корпоративное управление

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

Целью данной статьи, является описание способов синхронизации данных с помощью механизма двух фазной транзакции реализованных в корпоративной системе ОАО "РОСТОВЭНЕРГО", что повышает производительность всей системы в целом и позволяет пользователям взаимодействовать с системой в режиме реального времени. Новизна данной работы заключается, в том, что сам механизм двух фазной транзакции реализован различными средствами в различных архитектурных решениях:
на стороне клиента Swing приложения запускаемого по Web –start с помощью библиотеки Hibernate;
на сервере приложений с помощью менеджера распределенных транзакций JOTM;
в виде отдельной службы с планировщиком задач, для синхронизации данных с помощью Hibenate, JOTM и реестра rmiregistry;

Распределенная транзакция включает в себя несколько локальных транзакций, каждая из которых либо фиксируется, либо прерывается. Распределенная транзакция фиксируется только в том случае, когда зафиксированы все локальные транзакции, ее составляющие. Если хотя бы одна из них была прервана, то должна быть прервана и распределенная транзакция. Данный механизм может быть реализован как на распределенной БД, так и на множестве СУБД, имеющих часть общей информации необходимой для функционирования единой корпоративной системы [2].

Для этого в СУБД предусмотрен так называемый протокол двухфазовой фиксации транзакций (two-phase commit protocol - 2PC). Название отражает то, что фиксация распределенной транзакции выполняется в две фазы. Управляет транзакцией - менеджер распределенных транзакций, например JBoss, JOTM, WebSphere 6. Они, как правило, интегрируются в сервер приложений, но могут также работать в режиме standalone.

Первая фаза начинается, когда клиент выполняет оператор COMMIT. Менеджер транзакции направляет уведомление PREPARE TO COMMIT - "подготовиться к фиксации" всем серверам БД, выполняющим транзакцию. Последние после подготовки к фиксации остаются в состоянии готовности и ожидают от менеджера команды фиксации.

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

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

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

Аналогичная проблема, была решена нами в рамках задачи централизации корпоративной системы ОАО "РОСТОВЭНЕРГО". В единое корпоративное информационное пространство входит 7 серверов СУБД с MS SQL Server расположенных на филиалах по Ростовской области и один в аппарате управления. В общем случае задачу централизации была разбита на три подзадачи:
Ведение единого реестра, какого либо объекта, входящего в корпоративную информационную систему;
Синхронизация единого реестра со стороны центрального сервера;
Обеспечение доступа, в режиме реального времени, к распределенным сущностям.

Рассмотрим первую подзадачу на примере решения проблемы реализации механизма распределенной транзакции при ведении единого реестра договоров ОАО "Ростовэнерго". Договора могут заключаться на всех филиалах по Ростовской области. Можно выделить три типа договоров:
Договор, заключенный филиалом или аппаратом управления в своих интересах, если он заключен филиалом, то он должен быть сохранен на сервере аппарата управления и на сервере филиала, если аппаратом управления в своих интересах – то только на сервере аппарата управления.
Договор заключенный аппаратом управления в интересах филиала. Его необходимо сохранять на сервере филиала, в интересах которого он был заключен и на сервере аппарата управления.
Централизованный договор, заключенный аппаратом управления в интересах всех филиалов необходимо сохранять на сервере аппарата управления и на серверах всех филиалов.
Кроме того, любые изменения в договорах, должны быть реализованы по описанному выше взаимодействию см. рис.1.
Рисунок 1. Схема взаимодействия

юристов филиалов при добавлении и редактировании данных;
юристов филиалов при просмотре данных;
юристы управления при добавлении, редактировании и просмотре данных

При внесении нового договора, он в начале должен быть сохранен на сервер аппара-та управления, в результате договору присваивается идентификатор, после чего, он при необходимости сохраняется на сервере филиала. Аналогичным образом должно выпол-няться и редактирование.

На первом этапе был реализован механизм распределенной транзакции средствами Hibernate. При авторизации пользователя происходит его идентификация на LDAP - сер-вере, после чего клиентскому приложению передается информация о филиале, к которому принадлежит пользователь, и в зависимости от этого на стороне клиента создается либо две Hibernate – фабрики сессий, если он не принадлежит к аппарату управления либо одна в противном случае. Далее при сохранении объекта, см листинг 1, выполняется последо-вательное сохранение, вначале на центральном сервере, а потом на сервере филиала. При этом если COMMIT на центральном сервере прошел успешно, выполняется фиксация транзакции на сервере филиала. В случае неудачной фиксации на сервере филиала проис-ходит последовательный "откат" транзакции, см листинг 2. Несмотря на очевидное несо-вершенство данного механизма реализации двух фазной транзакции, который нами рас-сматривался как временный, переходный вариант, промышленная эксплуатация системы в течение четырех месяцев с его использованием показала довольно неплохие, на наш взгляд результаты. При вводе тысячей объектов с удаленных серверов имели место еди-ничные случаи, когда объект сохранялся на центральном сервере, а на сервере филиала отсутствовал. Анализ данных случаев показал, что 90% из них произошло из-за загружен-ности каналов связи между аппаратом управления и филиалом. Оставшиеся 10% связаны с загруженностью локального сервера СУБД.


Источник: http://www.javaportal.ru

Рекомендуем



Использование Hibernate Java Persistence На практике наибольшую популярность получили именно реляционные модели баз данных, хотя в современных методологиях программирования пользуется популярностью объектно-ориентированное программирование


Регулярные выражения в Java (regexp) Эти операции осуществляются с помощью универсальных символов, которые специальным образом интерпретируются


Проблемы реализации постраничной загрузки таблиц с помощью компонент Hibernate и Java Наиболее оптимальным компонентом является интерфейс ScrollableResults, который имеет все необходимые методы для перемещения по выборке, а использование класса DetachedCriteria, позволяет после выборки объектов закрыть сессию с СУБД