Модели транзакций. Свойства. Способы завершения

Поддержка транзакций

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

«Транзакция является логической единицей работы, выполняемой в базе данных. И может быть представлена отдельной программой, являться частью алгоритма или даже отдельной командой (например, командой INSERT или UPDATE языка SQL) и включать произвольное количество операций, выполняемых в базе данных. С точки зрения базы данных, выполнение программы некоторого приложе­ния может расцениваться как серия транзакций, в промежутках между которыми выполняется некоторая обработка данных, осуществляемая вне среды базы данных. Для иллюстрации концепции транзакции рассмотрим два отношения:

Staff (Sno, FName, LName, Address, Tel__No, Position, Sex, DOB, Salary, NIN, Bno)

Property_for_Rent (Pno, Street, Area, City, Pcode, Type, Rooms, Rent, Ono, Sno, Bno)

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

Более сложная транзакция предназначена для удаления сведений о работнике, заданном его учетным номером x. В этом случае, помимо удаления соответствующего кортежа из отношения Staff, по­требуется найти все кортежи отношения Property_for_Rent, описывающие объекты недвижимости, за которые отвечал данный работник, после чего назначить их неко­торому другому работнику, личный номер которого будет иметь значение new_sno, Если все указанные изменения не будут внесены до конца, база данных окажется в несогласованном состоянии - за объект недвижимости будет отвечать несуществую­щий работник компании.

Любая транзакция всегда должна переводить базу данных из одного согласован­ного состояния в другое, хотя допускается, что согласованность состояния базы будет нарушаться в ходе выполнения транзакции.

Любая транзакция завершается одним из двух возможных способов. В случае ус­пешного завершения результаты транзакции фиксируются (commit) в базе данных, и последняя переходит в новое согласованное состояние. Если выполнение транзакции не увенчалось успехом, она отменяется. В этом случае в базе данных должно быть восстановлено то согласованное состояние, в котором она находилась до начала дан­ной транзакции. Этот процесс называется откатом (roll back) транзакции. Зафикси­рованная транзакция не может быть отменена. Если оказывается, что зафиксирован­ная транзакция была ошибочной, потребуется выполнить другую транзакцию, отме­няющую действия, выполненные первой транзакцией. В некоторых случаях эту транзакцию называют компенсирующей. Следует отметить, что отмененная транзак­ция может быть еще раз запущена позже и, в зависимости от причин предыдущего отказа, вполне успешно завершена и зафиксирована в базе данных.

Никакая СУБД не обладает внутренней возможностью установить, какие именно изменения должны быть восприняты как единое целое, образующее одну логическую транзакцию. Следовательно, должен существовать метод, позволяющий указывать границы каждой из транзакций извне, со стороны пользователя. В большинстве язы­ков манипулирования данными для указания границ отдельных транзакций исполь­зуются операторы BEGIN TRANSACTION, COMMIT и ROLLBACK (или их эквиваленты). Если эти ограничители не были использованы, вся выполняемая программа расценивается как единая транзакция. СУБД автоматически выполнит команду COMMIT при нор­мальном завершении этой программы. Аналогично, в случае ее аварийного заверше­ния в базе данных автоматически будет выполнена команда ROLLBACK.

Свойства транзакций

Существуют некоторые свойства, которыми должна обладать любая из транзак­ций. Ниже представлены четыре основных свойства (ACID - аббревиатура, состав­ленная из первых букв их английских названий).

– Атомарность. Это свойство типа "все или ничего". Любая транзакция представляет собой неделимую единицу работы, которая может быть либо выполнена вся целиком, либо не выполнена вовсе.

– Согласованность. Каждая транзакция должна переводить базу данных из одного согласованного состояния в другое согласованное состояние.

– Изолированность. Все транзакции выполняются независимо одна от дру­гой. Другими словами, промежуточные результаты незавершенной тран­закции не должны быть доступны другим транзакциям.

– Продолжительность. Результаты успешно завершенной (зафиксированной) транзакции должны сохраняться в базе данных постоянно и не должны быть утеряны в результате последующих сбоев.

Улучшенные модели транзакций

Протоколы обработки транзакций, которые мы обсуждали до сих пор, больше всего подходят для тех типов транзакций, которые имеют место в традиционных бизнес-приложениях, при проведении банковских операций и в системах резервирования авиабилетов. Все эти приложения характеризуются следующими особенностями:

– Простые типы данных - целые числа, десятичные числа, короткие сим­вольные строки и даты.

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

– Рассмотрим различные средства разработки баз дан­ных, получивших в последнее время достаточно широкое распространение - инженерные (CAD), технологические (САМ) и программные (CASE). Все они имеют ряд общих характеристик, отличаю­щих их от традиционных приложений баз данных.

– Создаваемый проект может быть очень большим - вполне возможно, со­стоящим из миллионов частей, часто объединенных во множество взаимо­зависимых подсистем, представляющих собой отдельные проекты.

– Проект не является статическим объектом и постоянно эволюционирует. При внесении в проект изменения, его следствия часто распространяются на все имеющиеся в проекте подсистемы. Динамическая природа созда­ваемых проектов может означать, что некоторые действия просто не могут быть предусмотрены заранее, в самом начале работы.

– Выполняемые обновления могут иметь далеко идущие последствия, вызванные существующими сложными структурными взаимосвязями, функциональными зависимостями, допусками и т.д. Одно небольшое изменение вполне может оказать влияние на множество различных проектируемых элементов.

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

– В работу могут быть вовлечены сотни людей, работающих над нескольки­ми параллельными версиями одного крупного проекта. Тем не менее ко­нечный продукт должен быть согласованным и сбалансированным. Иногда такой стиль работы называют кооперативным проектированием. Коопера­ция требует четкого взаимодействия и полной согласованности всех разра­боток, выполняемых параллельно.

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

– С учетом фактора времени, продолжительные транзакции более чувстви­тельны к отказам. Было бы совершенно неприемлемо отменить выполнение подобной транзакции с потенциальной потерей очень большого объема вы­полненной работы. Следовательно, чтобы минимизировать возможные по­тери, необходимо иметь средства для восстановления того состояния тран­закции, которое она имела незадолго до возникновения отказа.

– С учетом фактора времени, продолжительные транзакции могут получать доступ (например, устанавливать блокировки) к очень большому количест­ву элементов данных. Во избежание возможного взаимного влияния тран­закций, все эти элементы станут недоступными другим приложениям вплоть до завершения данной транзакции. Однако крайне нежелательно, чтобы существенный объем данных оставался недоступным на протяжении достаточно продолжительного периода времени, поскольку это отражается на уровне параллельности обработки в системе.

– Чем дольше выполняется транзакция, тем вероятнее возникновение ситуа­ции взаимной блокировки, когда в системе используется протокол, допус­кающий подобные ошибки. Было показано, что вероятность возникновения взаимной блокировки пропорциональна четвертой степени времени выпол­нения транзакции (Gray, 1981).

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

Модель вложенных транзакций

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

Для модели вложенных транзакций Моссом был предложен и протокол управле­ния параллельностью, построенный по принципу жесткой двухфазной блокировки. Субтранзакции родительской транзакции выполняются так, как если бы они были независимыми транзакциями. Субтранзакциям разрешается устанавливать блоки­ровку элемента, если некоторая другая транзакция, уже установившая блокировку, с которой конфликтует данная субтранзакция, является ее родительской. Когда суб­транзакция завершает работу, установленные ею блокировки наследуются родитель­ской транзакцией. При наследовании блокировки родитель получает более эксклю­зивный режим блокировки, если и дочерняя, и родительская транзакции устанавли­вали блокировку одного и того же элемента данных.

Ниже перечислены основные преимущества модели вложенных транзакций.

– Модульность. Транзакция может быть разложена на произвольное количе­ство субтранзакций, что способствует повышению уровня параллельности обработки и расширяет возможности восстановления.

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

– Достижение параллельности обработки в пределах транзакции. Субтран­закции могут выполняться в параллельном режиме.

– Возможность управления восстановлением в пределах транзакции. Отме­ненные субтранзакции могут быть отброшены или проигнорированы без каких-либо побочных эффектов для других субтранзакций.

Эмуляция механизма вложенных транзакций с помощью точек сохранения

Точкой сохранения называется определенная точка в плоской транзакции, пред­ставляющая некоторое частично согласованное состояние, которая может быть ис­пользована как точка промежуточного рестарта транзакции в случае возникновения каких-либо проблем. Фактически, это одна из задач модели вложенных транзакций, состоящая в предоставлении некоторой единицы восстановления работы, более мел­кой, чем вся транзакция в целом. В процессе выполнения транзакции пользователь может организовать точку сохранения - например, с помощью оператора SAVE WORK. При его выполнении генерируется некоторый идентификатор, который пользователь впоследствии сможет применить для отката транзакции до данного, зафиксированно­го состояния - например, с помощью оператора ROLLBACK WORK идентификатор точки сохранений. Однако, в отличие от модели вложенных транзакций, при использовании точек сохранения не обеспечивается какая-либо из форм параллельности обработки в пределах транзакции.

Этот оператор не является стандартным оператором языка SQL и представляет собой лишь некоторую иллюстрацию.

Хроники

Концепция хроник (sagas), которая была введена Гарсия-Молином (Garsia-Molina) и Салемом (Salem) в 1987 г., построена на использовании понятия компенсирующих транзакций. Авторы определяют хронику как последовательность (плоских) тран­закций, которые могут чередоваться с прочими транзакциями. СУБД гарантирует, что либо все входящие в хронику транзакции будут успешно завершены, либо будут запущены компенсирующие транзакции, необходимые для устранения достигнутых частичных результатов. В отличие от метода вложенных транзакций, допускающего произвольный уровень вложения, метод хроник разрешает наличие единственного уровня вложения. Более того, для каждой выделенной субтранзакции должна суще­ствовать соответствующая компенсирующая транзакция, которая будет семантиче­ски аннулировать результаты, достигаемые с помощью данной субтранзакции. Таким образом, если имеется хроника, состоящая из последовательности п транзакций T1,T2,..., Тn с соответствующим набором компенсирующих транзакций С1, С2,..., Сn, то окончательный результат выполнения хроники будет определяться одной из сле­дующих последовательностей транзакций:

1) Т1,Т2,..., Тn - если вся транзакция была успешно завершена.

2) Ti, Tg,..., Т, Ci-1,..., Са, Ci - если выполнение транзакции Ti было прекращено.

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

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

Модель многоуровневых транзакций

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

Одним из вариантов модели открытых вложенных транзакций является модель многоуровневых транзакций, в которой дерево субтранзакций является сбалансиро­ванным (Weikum, 1991; Weikum and Schek, 1991). Узлы одного и того же уровня де­рева соответствуют операциям одного и того же уровня абстракции в СУБД. Ветви дерева представляют реализацию операции посредством последовательности опера­ций на следующем уровне глубины. Уровни n-уровневой транзакции обозначаются как l0, L1,..., Ln, где l0 - самый нижний уровень дерева, a Ln - корень дерева. Ме­тоды обработки обычных плоских транзакций гарантируют, что на самом нижнем уровне (L0) конфликты будут отсутствовать. Основная концепция модели многоуров­невых транзакций состоит в том, что две операции на уровне Li могут не конфликто­вать, даже если их реализации на следующем, более низком уровне Li-1 конфликту­ют. Используя преимущество знания информации о конфликтах на конкретном уровне, модель многоуровневых транзакций позволяет достичь более высокой степе­ни параллельности по сравнению с моделями обработки плоских транзакций.

Динамическая реструктуризация

В начале этого вопроса обсуждались некоторые особенности приложений под­держки выполнения различных проектов - например, неопределенная продолжи­тельность работы (от нескольких часов до месяцев), чередование с другими видами операций, неопределенность процесса обработки, не позволяющая предвидеть все ас­пекты работы с самого начала ее выполнения, и т.д. В обход ограничений, налагае­мых основными свойствами (ACID) плоских транзакций, были предложены две но­вые операции: разбиение транзакции (split_transaction) и объединение транзакций (join_transaction) (Pu et al., 1988). Принцип, положенный в основу операции разбие­ния транзакции, состоит в разделении активной транзакции на две упорядоченные транзакции и распределении между ними выполняемых действий и используемых ресурсов (например, заблокированных элементов данных). С этого момента вновь созданные транзакции могут независимо выполняться (возможно, даже под контро­лем разных пользователей) и обрабатываться так, как если бы они всегда были со­вершенно независимыми. Подобный подход позволяет сделать промежуточные ре­зультаты транзакции доступными другим транзакциям, причем с полным сохране­нием их семантики - другими словами, если исходная транзакция отвечала всем ACID-требованиям, то так же поведут себя и новые транзакции.

Операция разделения транзакции может применяться только в том случае, если возможно создать две транзакции, которые будут упорядочены друг с другом и со всеми другими выполняющимися в данный момент транзакциями. Условия, которые разрешают разделение транзакции Т на две транзакции, А и В, можно определить следующим образом.

1. AWriteSet Ç BWriteSet Í BWriteLast. Это условие утверждает, что если обе транзакции, А и В, выполняют запись в один и тот же элемент данных, то операция' записи транзакции В должна выполняться после операции записи транзакции А.

2. AReadSet Ç BWriteSet = Ø. Это условие утверждает, что транзакция А не мо­жет видеть никаких результатов выполнения транзакции В.

3. BReadSet Ç AWriteSet = ShareSet. Это условие утверждает, что транзакция В может видеть результаты выполнения транзакции А.

Приведенные выше условия гарантируют, что транзакция А в упорядоченном графике будет предшествовать транзакции В. Однако, если выполнение транзакции А будет прервано, выполнение транзакции В также необходимо будет отменить, по­скольку она использует данные, записанные транзакцией А. Если оба множества BWriteLast и ShareSet пусты, то транзакции А и В могут быть упорядочены в любой последовательности и работа их будет совершенно независимой.

Операция объединения транзакций выполняет обратные действия по отношению к операции разделения транзакций, сливая результаты работы двух или более неза­висимых транзакций так, как если бы эти транзакции всегда представляли собой единую транзакцию. Использование операций разделения транзакции, дополненных операциями объединения одной или больше вновь созданных транзакций, позволяет обмениваться ресурсами между определенными транзакциями, не делая эти ресурсы доступными другим транзакциям.

Основные достоинства метода динамической реструктуризации состоят в следующем.

– Адаптивное восстановление. Возможность зафиксировать часть выпол­ненной в транзакции работы, что исключает ее зависимость от последую­щих отказов.

– Снижение уровня изолированности. Возможность освободить часть исполь­зовавшихся в транзакции ресурсов посредством фиксации уже выполнен­ной части ее работы.

Модели рабочих потоков

Все обсуждавшиеся в этом разделе модели были разработаны с целью преодоления ограничений, накладываемых моделью плоских транзакций, не приемлемых для тран­закций большой продолжительности. Однако было отмечено, что все эти модели по-прежнему не обладают мощностью, необходимой для удовлетворения потребностей де­ловых процессов определенных видов. Поэтому были предложены более сложные моде­ли, представляющие собой комбинации моделей открытых и вложенных транзакций. Однако, поскольку эти модели слабо отвечают ACID-требованиям плоских транзакций, для них используется более подходящее название - модели рабочих потоков.

Рабочий поток представляет собой некоторый вид деятельности, предусматри­вающий координированное выполнение множества заданий, осуществляемых раз­личными субъектами обработки, которые могут представлять собой людей или не­которые программные комплексы (например, СУБД, прикладные программы или службы электронной почты

Перед любыми системами с рабочими потоками стоят две общие проблемы: опреде­ление рабочего потока и выполнение рабочего потока. Обе проблемы усложняются тем фактом, что во многих организациях одновременно используется несколько независи­мых компьютерных систем, предназначенных для автоматизации различных сторон общего процесса. Приведенные ниже определения выделяют ключевые элементы, ис­пользуемые при определении рабочего потока (Rusinkiewicz and Sheth, 1995).

– Спецификация задания - структура выполнения каждого задания, опре­деляемая посредством предоставления набора обозримых извне состояний процесса и набора переходов между этими состояниями.

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

– Требования к корректности выполнения - ограничения, накладываемые на показатели выполнения рабочего потока, с целью его соответствия тре­бованиям корректности в данном приложении. Сюда относятся требования по устойчивости к отказам, независимости и параллельности обработки, возможностям восстановления и т.д.

Процессам выполнения свойственна семантика открытой вложенности, допускаю­щая видимость промежуточных результатов процесса вне его границ и разрешающая различным компонентам фиксировать результаты своей работы в индивидуальном по­рядке. Компонентами могут быть другие субъекты обработки, характеризующиеся как семантикой открытой вложенности, так и семантикой закрытых вложенных транзак­ций, результаты функционирования которых будут видны всей системе только после полного завершения работы этого компонента. Следует отметить, что компоненты с се­мантикой закрытых вложенных транзакций могут состоять только из компонентов с семантикой того же типа. Некоторые из этих компонентов могут расцениваться как жизненно важные, и в случае отказа от их выполнения потребуется прекратить выпол­нение и их родительских компонентов. Кроме того, могут быть определены компенси­рующие и возможные (альтернативные) транзакции, речь о которых уже шла выше.

Дата добавления: 2015-05-09