Реферат: Обработка транзакций
По мере того как данные и вычисления становятся все более распределенными, атомарность плоских транзакций становится значительным неудобством. Рассмотрим пример на рис. 2. Согласно правилам обработки плоских транзакций, либо должны успешно завершиться все компоненты глобальной транзакции, либо не должна завершиться ни одна из них. Например, если неудачей завершилось только изменение одной удаленной базы данных под управлением некоторого менеджера ресурсов, то и все остальные компоненты должны быть возвращены в состояние, предшествовавшее началу транзакции. Учитывая количество информации, обрабатываемой в крупной или даже средней организации со множеством серверов LAN на ПК и, возможно, с мобильными базами данных, можно предположить, что вероятность отказа хотя бы одного узла весьма высока. Если применяется модель плоских транзакций, то придется заново выполнять все составные части транзакции, что существенно повышает требования к вычислительным ресурсам и отнимает значительную долю пропускной способности системы.
Рисунок 2. Выполнение плоской транзакции в среде крупной организации.
Очевидно, что в наш век сильно распределенных вычислений необходимо каким-то образом проводить декомпозицию плоских транзакций. Модификация модели плоских транзакций, сохраняющая свойство атомарности, но снижающая потребность в повторном выполнении действий (т. е. в "переработках"), включает понятие контрольных точек, которое мы обсудим в следующем разделе.
2.2. Контрольные точки
Контрольные точки устанавливаются в прикладной программе для того, чтобы отметить моменты, начиная с которых можно продолжить вычисления в случае возникновения проблем. В идеале контрольные точки должны соответствовать частично согласованным состояниям (например, после построения вспомогательной таблицы в программе, которая затем будет использоваться для вычислений с участием еще какой-либо таблицы).
По достижении очередной контрольной точки в транзакции создается новое атомарное действие, которое запускается на выполнение. Только последнее атомарное действие всей последовательности может выполнить фиксацию (COMMIT WORK) транзакции; оператор COMMIT WORK передается всем предыдущим атомарным действиям, пока все они не будут зафиксированы. В отличие от модели многозвенных транзакций, которые мы рассмотрим в следующем разделе, контрольная точка не приводит к необратимой фиксации, выполненной до этого момента работы.
Прерывания (ROLL BACK), или откаты, транзакции могут инициироваться из любого атомарного действия, а не только из последнего; хотя в любой заданный момент времени прерывание может инициировать только действие, запущенное последним. (Это значит, что если для какого-то атомарного действия была достигнута контрольная точка, то для этого действия уже не может быть в дальнейшем принято решение об откате.) Откат может быть произведен до любой из предыдущих контрольных точек, поэтому менеджер обработки транзакций должен воспринимать параметр, указывающий, до какой именно контрольной точки нужно произвести откат (в идеале логика приложения должна предусматривать определение контрольной точки, до которой в случае неудачи следует откатить выполнение).
Проводились исследовательские работы по изучению применимости так называемых устойчивых (persistent) контрольных точек, которые фиксируются в дисковой или другой долговременной памяти, для того чтобы результаты выполнения были доступны после системных крахов. Однако Грей и Реутер отмечают, что "здесь не видно пока никакого решения, которое можно было бы принять безоговорочно". Это вряд ли следует считать большой проблемой, поскольку две новые модели транзакций - вложенные и многозвенные транзакции - предоставляют схожие возможности при том, что формальные определения этих парадигм значительно лучше проработаны и общеприняты. Рассмотрим вначале многозвенные транзакции.
2.3. Многозвенные транзакции
Модель многозвенных транзакций (рис. 3) концептуально подобна модели контрольных точек, но она предполагает фиксацию части работы, сделанной до некоторого момента; возможность отката зафиксированных действий исключается.
Рисунок 3. Концептуальное представление многозвенных транзакций.
Приложение тем не менее остается в состоянии транзакции; т. е. при этом не происходит инициации очередной транзакции, ее завершения, инициации следующей и ее завершения и т. д. В рамках многозвенной транзакции сохраняются все необходимые элементы контекста выполнения (курсоры баз данных, открытые файлы и т. д.), хотя ресурсы, ставшие ненужными, можно освобождать.
Модель многозвенных транзакций включает оператор CHAIN WORK - неделимую комбинацию операторов COMMIT WORK и BEGIN WORK, - которая неравноценна последовательному выполнению операторов COMMIT WORK и BEGIN WORK по отдельности. При выполнении этих операторов по отдельности контекст пропадает; некоторая другая транзакция может "вклиниться" и изменить значения в базе данных, которые нужны для выполнения следующего "звена" многозвенной транзакции, прежде чем это звено начнет выполняться. Таким образом, многозвенные транзакции концептуально эквивалентны транзакциям с контрольными точками с той разницей, что откат может производиться только до последней зафиксированной точки, а не до любой предыдущей контрольной точки.
Обе модели транзакций - многозвенные и с контрольными точками - позволяют описывать последовательности действий; различия касаются лишь возможностей отката и устойчивости выполненных до заданной точки действий. Последняя модель, которую мы обсудим, - это модель, которая позволяет описывать не последовательности, а иерархии субтранзакций.
2.4. Вложенные транзакции
Модель вложенных транзакций включает понятие головной транзакции, которая управляет выполнением всей иерархии. В рамках иерархии могут присутствовать транзакции разных уровней вложенности (рис. 4). Концевые узлы иерархии представляют собой плоские транзакции. Отдельные ветви иерархии могут иметь разную длину, т. е. концевые транзакции могут находиться на разном "расстоянии" от головной транзакции (корня дерева транзакций).
Рисунок 4. Структура вложенных транзакций.
Правила и модели вложенных транзакций были впервые разработаны Эллиотом Моссом в 1981 году. В модели Мосса реальные действия могли производиться только концевыми субтранзакциями, но Грей и Реутер отмечают, что это правило ограничивает функции вложения транзакций и, что его отмена дает дополнительные возможности распараллеливания действий над разделяемыми объектами при введении абстракции многоуровневых объектов.
Мосс сформулировал три правила для управления вложенными транзакциями:
- Правило фиксации. Выполнение оператора COMMIT WORK в некоторой субтранзакции делает ее результаты видимыми только для родительской транзакции. Фактическая фиксация субтранзакции происходит только после фиксации всех ее предков вплоть до головной транзакции.
- Правило прерывания (отката). Если субтранзакция некоторого уровня, включая головную, откатывается, то же самое должно быть сделано для всех ее потомков, независимо от статуса фиксации любой из них на локальном уровне.
- Правило видимости. Все действия, выполненные в рамках субтранзакции, при ее фиксации становятся видимыми родительской транзакции. Все объекты, захваченные некоторой транзакцией, доступны ее потомкам. Соседние транзакции (относящиеся к одному уровню и имеющие общего родителя) "не видны" друг другу ни в том, ни в другом смысле, что позволяет выполнять их параллельно.
Из свойств ACID для субтранзакций выполняются свойства атомарности, согласованности и изолированности. Но поскольку COMMIT WORK для субтранзакции на самом деле не означает ее фиксации до фиксации всей транзакции, то свойство долговечности не выполняется, поэтому субтранзакции не эквивалентны плоским транзакциям.
Как и другие модели, вложенные транзакции имеют вариации, в том числе модель многоуровневых (multilevel) транзакций, где субтранзакция ST1 "предварительно фиксирует" свои результаты. При этом для нее предусмотрена компенсирующая субтранзакция, которая может отменить выполненные ST1 действия, если происходит прерывание всей транзакции в целом. Компенсирующие транзакции позволяют отменять результаты почти в реальном времени; в их отсутствие приходится применять сценарии восстановления с анализом времени произведенных изменений, для чего используются дорогостоящие оперативные ресурсы, обеспечивающие возврат базы данных в согласованное состояние (например, с применением журналов или путем "сопоставления фрагментов" головоломки-мозаики, для того чтобы определить, каким должно быть согласованное состояние базы данных).
Хотя можно представить себе приложения и системы, в которых многозвенные и вложенные транзакции были бы полезны, однако лишь в начале 90-х годов в коммерческих приложениях на смену плоским транзакциям начали приходить другие. Интересно, впрочем, отметить, что при изучении транзакций SQL можно обнаружить некоторые признаки "псевдовложенности", по крайней мере в способах обработки операторов (это в настоящее время недоступно разработчикам приложений; однако принятый в настоящее время стандарт SQL3 содержит контрольные точки и, вероятно, в него войдут операторы управления многозвенными транзакциями).
На рис. 5 показано выполнение транзакции SQL. Каждый оператор внутри транзакции, которая представляет собой, например, последовательность операторов UPDATE и DELETE, может завершиться успешно или неуспешно. Даже если один или несколько операторов завершаются неудачей, транзакция в целом может продолжаться, если в ее логике для этих случаев явно не предусмотрено прерывание с откатом в начальное состояние. Все успешно завершившиеся до прерывания операторы (которые в этой модели можно представлять как субтранзакции) будут отменены, если происходит откат всей транзакции.
Рисунок 5. SQL как модель псевдовложенных транзакций.
Разработчикам приложений приходилось как-то компенсировать недоступность имеющихся в SQL свойств псевдовложенности, применяя различные ухищрения для построения архитектур транзакций, более соответствующих их потребностям, чем простейшие плоские транзакции. Когда на рынке утвердится стандарт SQL3, и начнут появляться совместимые с ним продукты, разработчики приложений на основе SQL СУБД смогут непосредственно пользоваться преимуществами новых моделей транзакций.
3. Encina и DCE
Монитор обработки транзакций Encina корпорации Transarc можно рассматривать как коммерческий продукт второго поколения, однако более развитый, отражающий новейшие достижения в этой области. Encina включает модель вложенных транзакций и расширяет возможности среды DCE (Distributed Computing Environment), предложенной организацией OSF (Open Software Foundation).
Прообразом Encina был прототип системы обработки транзакций Camelot, разработанный в университете Карнеги-Меллон в Питтсбурге. Технология, лежащая в основе Camelot, и применяемый в этой системе язык программирования Avalon описаны в работе Camelot and Avalon: A Distributed Transaction Processing Facility. Camelot считается "первой реализацией вложенных транзакций в системе обработки транзакций" (в отличие от псевдовложенности, которую мы обсуждали в предыдущем разделе, или от внутрисистемной вложенности, недоступной для разработчиков приложений).
Архитектура, которая отражена на рис. 6, соответствует степени распределенности, характерной для разрабатываемых или проектируемых в настоящее время информационных систем. Использование серверов приложений здесь соответствует философии выделения процедур обработки данных, в отличие от философии выделения самих данных. Хотя пользователи, имеющие достаточные полномочия, могут непосредственно осуществлять доступ к удаленным данным, но в данном случае цель состоит в том, чтобы полностью передать управление данными серверам приложений.
Рисунок 6. Открытая прикладная среда распределенной обработки транзакций.
На рис. 7 изображен типичный многоуровневый подход к распределенной обработке транзакций, применяемый, в частности, в DCE. Монитор Encina использует предоставляемые DCE абстрактные уровни управления ресурсами и коммуникационных менеджеров и сам обеспечивает прямое подключение к ресурсам и коммуникационным менеджерам, не подчиненным DCE. Модульность и многоуровневость - черты, характерные для современных открытых систем и корпоративных вычислительных архитектур, - находят отражение и в обработке транзакций. Можно с уверенностью предположить, что концепции открытых систем в дальнейшем будут еще более активно применяться в сфере обработки транзакций.
Рисунок 7. Многоуровневая архитектура обработки транзакций в Encina.
Одна из задач, решаемых монитором Encina, - это поддержка свойств ACID в среде баз данных клиент-сервер при условии, что клиенты и серверы независимо хранят записи о состоянии транзакций.
В Encina код, обеспечивающий соблюдение свойств ACID, заключен в менеджерах ресурсов (см. рис. 7); приложения и другие программы верхнего уровня выдают запросы на фиксацию или прерывание транзакций, которые менеджеры транзакций реализуют на соответствующих ресурсах нижнего уровня.
Encina включает язык разработки приложений Transactional C, содержащий набор макросов и библиотек для определения транзакций и управления ими. Ключевое слово TRANSACTION служит для определения транзакций верхнего уровня или вложенных. Функции, задаваемые при помощи ключевых слов ONABORT и ONCOMMIT, описывают действия, выполняемые при откате или, соответственно, фиксации транзакции любого уровня. Программа может вызвать ENCINA_ABORT_ALL, чтобы вызвать прерывание всей транзакции.
Интересно было бы понаблюдать, как пойдет развитие не только конкретного продукта Encina, но и всей области "открытой обработки транзакций" в целом. Тенденции усиления распределенности и неоднородности, которые направляют развитие технологий баз данных и информационного управления, требуют определенной степени открытости всех компонентов информационных систем (в том числе сервисов операционных систем, безопасности, баз данных, мониторов транзакций). Хотя старые "закрытые" продукты и аппаратные платформы, поддерживаемые ими, просуществуют еще довольно долго, но тенденции, которые иллюстрирует рис. 8, неизбежно будут оказывать все более значительное влияние на развитие систем обработки транзакций.
Рисунок 8. Факторы, влияющие на развитие коммерческих мониторов обработки транзакций.