Диспетчер транзакций

Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ, то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД.

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

Параллелизм

Термин параллелизмозначает возможность одновременной обработки в СУБД многих транзакций с доступом к одним и тем же данным, причем в одно и то же время. Как известно, в такой системе для корректной обработки параллельных транзакций без возникновения конфликтных ситуаций необходимо использовать некоторый метод управления параллелизмом. Следующие конфликтные ситуации, которые могут привести к получению неправильного результата из-за взаимных помех среди некоторых транзакций, возможны при отсутствии соответствующего управления (заметьте, что вносящая помеху транзакция сама по себе может быть правильной):

• Проблема потери результатов обновления;

• Проблема незафиксированной зависимости;

• Проблема несовместимого анализа.

Проблема потери результатов обновления

Рассмотрим ситуацию, показанную на рис.9: транзакция А извлекает некоторый кортеж р в момент времени t1; транзакция В извлекает некоторый кортеж в момент времениt2; транзакция А обновляет некоторый кортеж р (на основе значений, полученных в момент времениt1) в момент времениt3; транзакция В обновляет тот же кортеж р (на основе значений, полученных в момент времениt2, которые имеют те же значения, что и в момент времениt1) в момент времениt4. Однако результат операции обновления, выполненной транзакцией А будет утерян, поскольку в момент времениt4 она не будет учтена и потому будет «отменена» операцией обновления, выполненной транзакцией В.

Транзакция А	Время	Транзакция В
-		-
Извлечение кортежа р	t1	-
-		-
	t2	Извлечение кортежа р
-		-
Обновление кортежа р	t3	-
-		-
	t4	Обновление кортежа р

Рис.9. Потеря результатов обновления транзакции А

Проблема незафиксированной зависимости

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

Транзакция А	Время	Транзакция В
-		-
	t1	Обновление кортежа р
-		-
Извлечение кортежа р	t2
-		-
	t3	Отмена выполнения транзакции
-		-

Рис.10. Транзакция А становится зависимой от невыполненного изменения в момент времени t2

В первом примере (рис.10) транзакция А в момент времени t2 встречается с невыполненным обновлением. Затем это обновление отменяется в момент времениt3. Таким образом, транзакция А выполняется на основе фальшивого предположения, что кортеж р имеет некоторое значение в момент –времениt2, тогда как на самом деле он имеет некоторое значение, существовавшее еще в момент времениt1. В итоге после выполнения транзакции А будет полечен неверный результат. Следует обратить внимание на то, что отмена выполнения транзакции В может произойти не по ее вине, а, например, в результате краха системы. К этому времени выполнения транзакции А может быть уже завершено, а потому крушение системы не приведет к отмене выполнения транзакции А.

Транзакция А	Время	Транзакция В
-		-
	t1	Обновление кортежа р
-		-
Обновление кортежа р	t2
-		-
	t3	Отмена выполнения транзакции
-		-

Рис.11. Транзакция А обновляет невыполненное изменение в момент времени t2, и результаты этого обновления утрачиваются в момент t3

Второй пример (рис.11) иллюстрирует более «ужасный» случай. Не только транзакция А становится зависимой от изменения, не выполненного в момент времени t2, но также в момент времениt3 фактически утрачивается результат обновления, поскольку отмена выполнения транзакции В в момент времениt3 приводит к восстановлению кортежа р в состояние на момент времениt1.

СЧЕТ 1 40	СЧЕТ 2 50	СЧЕТ 3 30
Транзакция А	Время	Транзакция В
-		-
Извлечение кортежа СЧЕТ 1 sum= 40	t1	-
Извлечение кортежа СЧЕТ 2 sum= 90	t2	-
	t3	Извлечение кортежа СЧЕТ 3
	t4	Обновление кортежа СЧЕТ 3 30 20
-	t5	Извлечение кортежа СЧЕТ 1
-	t6	Обновление кортежа СЧЕТ 1 40 50
	t7	Завершение вып. Транзакции
Извлечение кортежа СЧЕТ 3 sum= 110 (а не 120)	t8
	

Рис.12. Транзакция А выполнила несовместимый анализ

Проблема несовместимого анализа

На рис.12 показаны транзакции А и В, которые выполняются для кортежей со счетами (СЧЕТ). При этом транзакция А суммирует балансы, транзакция В производит перевод суммы 10 со счета 3 на счет 1. Полученный в итоге транзакции результат 110, очевидно, неверен, и если он будет записан в базе банных, то в ней может возникнуть проблема несовместимости. В этом случае говорят, что был выполнен несовместимый анализ. Следует обратить внимание на то, что в этом случае речь не идет о зависимости транзакции А от транзакции В, так как транзакция В выполнила все обновления до того, как транзакция А извлекла счет 3.

Блокировка

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

Более подробно это выглядит следующим образом.

1. Предположим, что в системе поддерживается два типа блокировок:блокировки без взаимного доступа (монопольная блокировка),называемая Х-блокировкой, иблокировка с взаимным доступом, называемаяS-блокировкой. Иногда эти блокировки называютблокировками записи и чтения соответственно.

2. Если транзакция А блокирует кортеж р без возможности взаимного доступа, то запрос другой транзакции В с блокировкой этого кортежа р будет отменен.

3. Если транзакция А блокирует кортеж р с возможностью взаимного доступа, то – запрос со стороны некоторой транзакции В на Х-блокировку кортежа будет отвергнут; - запрос со стороны некоторой транзакции В на S-блокировку кортежа р будет принят (т.е. транзакция В также будет блокировать кортеж р с помощьюS-блокировки.

	X	S	-
X	N	N	Y
S	N	Y	Y
-	Y	Y	Y

Рис.13. Матрица совместимости для Х- и S-блокировки

Эти правила можно наглядно представить в виде матрицы на рис.13. символы Sи Х обозначают блокировки, а прочерк – отсутствие блокировки.Nобозначает конфликтную ситуацию (запрос со стороны другой транзакции не может быть удовлетворен, а сама эта транзакция переходит в состояние ожидания), аY– полную совместимость (запрос удовлетворяется).

Теперь следует ввести протокол доступа к данным

1. Транзакция, предназначенная для извлечения кортежа, прежде всего, должна наложить S-блокировку на этот кортеж.

2. Транзакция, предназначенная для обновления кортежа, прежде всего должна наложить Х-блокировку на этот кортеж.

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

4. Х-блокировки сохраняются вплоть до конца выполнения транзакции (до операции «завершение выполнения» или «отмена выполнения»).

Посмотрим теперь, к чему приведет следование протоколу блокировки в рассмотренных выше примерах с проблемами параллелизма.

Проблема потери результатов обновления

На рис.14 показана измененная версия процесса, показанного на рис.9. операция обновления для транзакции А в момент времени t3 не будет выполнена, поскольку она является неявным запросом с заданием Х-блокировки для кортежа р, а этот запрос вступает в конфликт сS-блокировкой, уже заданной транзакцией В. Таким образом, транзакция А переходит в состояние ожидания. По аналогичным причинам транзакция В переходит в состояние ожидания в момент времениt4. Хотя в этом случае результаты любых обновлений не будут утрачены, решение проблемы сталкивается с другой проблемой, называемойтупиком.

Проблема незафиксированной зависимости

На рис.15 приведен пример, объединяющий два случая, показанных на рис.10 и 11. Операция для транзакции А в момент времени t2 (извлечение или обновление) не будет выполнена. Дело в том, что она является неявным запросом с заданием блокировки для кортежа р, а этот запрос вступает в конфликт с Х-блокировкой, уже заданной транзакцией В. таким образом, транзакция А переходит в состояние ожидания до тех пор, пока не будет прекращено выполнение транзакции В. тогда заданная транзакцией блокировка будет снята и транзакция А может быть выполнена. Причем транзакция А будет иметь дело с некоторым фиксированным значением (либо существовавшим до выполнения транзакции В при отмене ее выполнения, либо полученной после выполнения транзакции В). в любом случае транзакция А больше не зависит от незафиксированного обновления.

Транзакция А	Время	Транзакция В
-		-
Извлечение кортежа р (задание S-блокировки)	t1	-
-		-
	t2	Извлечение кортежа р (задание S-блокировки)
-		-
Обновление кортежа р (задание Х-блокировки)	t3	-
Ожидание		-
Ожидание	t4	Обновление кортежа р (задание Х-блокировки)
Ожидание		Ожидание

Рис.14. Хотя обновления не утрачиваются, в момент времени t4 возникает тупиковая ситуация

Транзакция А	Время	Транзакция В
-		-
	t1	Обновление кортежа р (задание Х-блокировки)
-		-
Извлечение кортежа р (задание S-блокировки) или Обновление кортежа р (задание Х-блокировки)	t2
Ожидание		-
Ожидание	t3	Окончание или отмена выполнения транзакции (снятие Х-блокировки)
Итог: Извлечение кортежа р (задание S-блокировки) или Обновление кортежа р (задание Х-блокировки)	t4

Рис.15. Транзакция А предохраняется от выполнения операций с незафиксированным изменением в момент времени t2

Проблема несовместимого анализа

На рис.16 показана измененная версия рис.12 согласно протоколу блокировки. Операция обновления для транзакции В в момент времени t6 на будет выполнена, поскольку она является неявным запросом с заданием Х-блокировки для кортежа СЧЕТ1, а этот запрос конфликтует сS-блокировкой, уже заданной транзакцией А. Таким образом, транзакция В переходит в состояние ожидания. Точно так же операция извлечения для транзакции А в момент времениt7 не будет выполнена. Дело в том, что она является невяным запросом с заданиемS-блокировки для кортежа СЧЕТ 3, а этот запрос конфликтует с Х-блокировкой, уже заданной транзакцией В. таким образом транзакция А переходит в состояние ожидания. Следовательно, блокировка хотя и помогает решить одну проблему (несовместимости анализа), но приводит к необходимости решения другой проблемы, а именно, возникновения тупиковой ситуации, которая обсуждается ниже.

Тупиковая ситуация

Как было показано выше, блокировку можно использоваться для разрешения трех основных проблем, возникающих при параллельной обработке кортежей. К сожалению, использование блокировок приводит к возникновению другой проблемы – тупиковой ситуации. На рис.17 показан обобщенный пример этой проблемы, в котором р1 и р2 представляют собой блокируемые объекты.

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

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

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

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

СЧЕТ 1 40	СЧЕТ 2 50	СЧЕТ 3 30
Транзакция А	Время	Транзакция В
-		-
Извлечение кортежа СЧЕТ 1 (задание S-блокировки для кортежа СЧЕТ 1) sum= 40	t1	-
Извлечение кортежа СЧЕТ 2 (задание S-блокировки для кортежа СЧЕТ 2) sum = 90	t2	-
	t3	Извлечение кортежа СЧЕТ 3 (задание S-блокировки для кортежа СЧЕТ 3)
	t4	Обновление кортежа СЧЕТ 3 (задание Х-блокировки для кортежа СЧЕТ 3) 30 20
-	t5	Извлечение кортежа СЧЕТ 1 (задание S-блокировки для кортежа СЧЕТ 1)
-	t6	Обновление кортежа СЧЕТ 1 (задание Х-блокировки для кортежа СЧЕТ 1)
		Ожидание
Извлечение кортежа СЧЕТ 3 (задание S-блокировки для кортежа СЧЕТ 3)	t7	Ожидание
Ожидание		Ожидание
Ожидание		Ожидание
	

Рис.16. проблема несовместимости разрешается, но в момент времени t7 возникает тупиковая ситуация

Например, в MSAccessпри попытке двух пользователей «одновременно» модифицировать одну и ту же запись один из них получит сообщение примерно такого содержания: «Пользователь на машине Х уже изменил данную запись. Перезаписать?». В результате можно выбрать один из трех вариантов:

• Перезаписать (Да) – будут зафиксированы изменения внесенные данным пользователем;

• Отказаться от перезаписи (Нет) – будут зафиксированы изменения, внесенные другим пользователем;

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

Транзакция А	Время	Транзакция В
-		-
Блокировка р1 без взаимного доступа	t1	-
-		-
	t2	Блокировка р2 без взаимного доступа
-		-
Блокировка р2 без взаимного доступа	t3	-
Ожидание		-
Ожидание	t4	Блокировка р1 без взаимного доступа
Ожидание		Ожидание
Ожидание		Ожидание
Ожидание		Ожидание

Рис.17. Пример тупиковой ситуации

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

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

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

2. Следовательно, выполнение транзакций одна за другой в любом последовательном порядке (используются независимые друг от друга транзакции) также является верным.

3. Чередующееся выполнение транзакций, следовательно, является верным, если оно эквивалентно некоторому последовательному выполнению, т.е. если оно подлежит упорядочиванию.

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

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

Следует подчеркнуть, что при выполнении двух различных последовательных графиков запуска, можно получить совершенно различные результаты. Поэтому выполнение двух различных чередующихся графиков запуска с одинаковыми транзакциями может также привести к различным результатам. Например, предположим, что транзакция А означает действие «сложить 1 с х», а транзакция В – «удвоить х». Пусть начальное значение х равно 10. Тогда при последовательном выполнении сначала транзакции А, а затем В будет получен результат х = 22, а при последовательном выполнении сначала транзакции В, а затем транзакции А – х = 21. Оба результата одинаково верные, а любой график запуска также является верным. Есвараном (Eswaran) доказал важную теоремудвухфазной блокировки, которая формулируется следующим образом:

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

При этом протокол двухфазной блокировкиформулируется следующим образом:

1. Перед выполнением каких-либо операций с некоторым объектом транзакция должна заблокировать этот кортеж.

2. После снятия блокировки транзакция не должна накладывать никаких других блокировок.

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

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

• Как только транзакция освободит некоторый установленный ею блок, она уже не имеет права затребовать блокировки новых элементов.

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

Транзакция А	Время	Транзакция В
-		-
Задание Х-блокировки	t1	-
Извлечение кортежа р	t2	Задание Х-блокировки
Обновление кортежа р	t3	Ожидание
Снятие блокировки	t4	Ожидание
	t5	Извлечение кортежа р -
	t6	Обновление кортежа р
	t7	Снятие блокировки

Рис.18. Решение проблемы потерянного обновления с помощью протокола двухфазной блокировки