Проектирование транзакций для приложений информационных систем

УДК 004.6 
М79 

Р е ц е н з е н т 
кандидат технических наук, доценте.С. Кожаринов 

Морозов Е.А. 

М79 
Проектирование транзакций для приложений информационных 
систем: Учеб. пособие. - М.: МИСиС, 2004. - 62 с. 

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

Содержание пособия соответствует программе курса «Проектирование 
информационных систем». 

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

Предназначено 
для 
студентов, 
обучающихся 
по 
специальностям 
3514э «Прикладная информатика» и 200200 «Автоматизированные системы 
обработки информации и управления». 

© Московский государственный институт 
стали и сплавов (Технологический 
университет) (МИСиС), 2004 

ОГЛАВЛЕНИЕ 

Введение 
4 

1. Понятие транзакции 
5 

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

3. Модели транзакций 
7 

4. Типовая структура транзакций 
9 

5. Возможные случаи завершения транзакций 
11 

6. Блокирование информационных объектов базы данных 
12 

7. Явное и неявное блокирование 
16 

8. Параллельное исполнение транзакций 
20 

9. Проблемы параллелизма 
23 

10. Возникновение тупиковых ситуаций и их устранение 
29 

11. Задание уровней изоляции транзакций 
31 

12. Управление параллелизмом с помощью временных меток 
33 

13. Оптимистические технологии управления параллелизмом 
35 

14. Усиление параллелизма посредством вложенных подтранзакций ..39 
15. Регистрация и завершение транзакций 
43 

16. Задачи проектирования транзакций 
45 

17. Определение состава прикладных программ, реализующих 
транзакции 
46 

18. Выделение и анализ конфликтующих транзакций 
51 

19. Уменьшение времени исполнения длинных транзакций 
54 

Заключение 
58 

Контрольные вопросы и задания 
59 

Библиографический список 
61 

3 

ВВЕДЕНИЕ 

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

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

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

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

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

Для простоты изложения предполагается, что приложения разрабатываются с использованием встроенного SQL (хотя все это также 
относится и к приложениям с прикладным API). 

4 

1. ПОНЯТИЕ ТРАНЗАКЦИИ 

Изучение транзакций начнем с рассмотрения двух простых 
примеров: 

1) бронирование билета на авиарейс; 
2) перевод денег с одного банковского счета на другой. 
Чем характерны эти примеры? Они представляют собой некие 
вычислительные работы. Причем и в том, и в другом случае эти работы связаны с выполнением двух операций. 

Бронирование билета предполагает запись о занятии определенного места и уменьшение числа свободных мест на единицу. Перевод 
денег означает снятие некоторой суммы с одного счета и зачисление 
этой суммы на другой счет. Иными словами, выполнение каждой из 
этих работ связано с выполнением в базе данных двух обновлений 
(под обновлениями здесь понимаются операции INSERT, DELETE и 
непосредственно UPDATE). 

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

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

Транзакция - логически неделимая вычислительная работа над 
базой данных, переводящая ее из одного непротиворечивого состояния в другое непротиворечивое состояние [1]. 

Это понятие транзакции возникло в 1970-1972 гг. и достаточно 
долго использовалось (хотя справедливости ради надо отметить, что 
были и другие определения, в которых также достаточно часто транзакция рассматривалась как единица восстановления). Тем не менее 
это определение транзакции так окончательно и не утвердилось. Фактически с 1972 по 1990-е годы понятие транзакции во многих научных 
работах часто искажалось. Существовала страшная путаница не только в советской литературе, но и у американцев, которые называли 

5 

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

Конец этой неразберихи был положен предложением американского института по стандартизации ANSI/ISO, который дал формальное определение транзакции. В настоящее время термин транзакция устойся. 

По ANSI/ISO транзакция - это некоторая последовательность 
операторов SQL, заканчивающаяся оператором COMMIT - завершить транзакцию (этот оператор также является оператором SQL). 

2. СВОЙСТВА ТРАНЗАКЦИЙ 

Определение транзакции, по ANSI/ISO, кратко, но совершенно 
неинформативно. Поэтому его принято пояснять следующими свойствами транзакций (ACID): 

1) атомарность (неделимость). Означает, что транзакция является логически неделимой вычислительной работой, исполняемой по 
щаятщ: 
все или ничего
2) непротиворечивость. Означает, что в результате действия 
транзакции БД должна переводиться из одного непротиворечивого 
состояния в другое непротиворечивое состояние; 

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

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

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

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

6 

3. МОДЕЛИ ТРАНЗАКЦИЙ 

Определение транзакции по ANSI/ISO молчаливо допускает наличие в ней любых операторов любого алгоритмического языка. Кроме 
того, в определении не сказано о том, что считать началом транзакции, 
поэтому согласно ANSI/ISO началом транзакции считается любой 
оператор SQL, в том числе и SELECT (оператор выборки). 

Эта идеология ANSI/ISO получила название модели транзакции 
ANSI/ISO. 

Существует еще расширенная модель, иногда называемая в литературе моделью SYBASE. Хотя, если быть точным, оба названия не 
отражают истины, так как эта модель появилась не в SYBASE и при 
этом задолго до модели ANSI/ISO. Фактически эта вторая модель 
была первой. Именно она появилась в 1970-1972 гг. 

Согласно определению по второй модели транзакция - это последовательность (совокупность) операторов SQL, начинающихся с 
оператора BEGIN TRANSACTION, заканчивающаяся оператором 
COMMIT и допускающая использование специальных операторов 
SAVE TRANSACTION (рис. 3.1). 

MoдeльANSI/ISO 
Расширенная модель 

SELECT 

... 

UPDATE 

... 

COMMIT 

Любые операторы 
^встроенного языка 

^ 

BEGIN TRANSACTION 

SELECT 

UPDATE 

SAVE TRANSACTION A 

INSERT 

SAVE TRANSACTION 

COMMIT 

Рис. 3.1. Модели транзакций 

7 

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

Наличие оператора BEGIN TRANSACTION делает эту модель 
принципиально отличной от модели ANSI/ISO. Хотя, на первый 
взгляд, различие кажется несущественным. Но это только на первый 
взгляд. В действительности наличие этого оператора означает, что 
разработчик приложений может существенно влиять на производительность разрабатываемой системы, оставляя некоторые операторы 
SQL вне рамок транзакций. Например, он может в некоторых случаях прочитать данные, используя оператор SELECT, считая при этом, 
что он не является транзакцией. В данном случае при исполнении 
приложения СУБД не включит механизм управления транзакциями 
и, следовательно, у системы не будет непроизводительных затрат 
времени. Однако оборотной стороной этой возможности является 
риск получения недостоверных данных или даже потери целостности 
БД (в случае, если разработчик не будет объявлять операторы модификации UPDATE, DELETE, INSERT транзакцией). 

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

Из этого видно, что модель ANSI/ISO является альтернативной. 
Она ограничивает творческие возможности разработчиков в смысле 
обеспечения 
наибольшей производительности при исполнении 
приложений, но на 100 % гарантирует сохранение целостности БД. 
Иными словами, эта модель ориентирована на рядового разработчика, предполагается также, что разработчик может быть весьма 
низкой квалификации и не знать про транзакции (как будет показано в разд. 5, оператор COMMIT в приложениях может быть опущен, следовательно, неквалифицированный разработчик может не 
знать и о нем). 

8 

4. ТИПОВАЯ СТРУКТУРА ТРАНЗАКЦИЙ 

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

Начало 
транзакции 

Любые операторы 
встроенного языка 

ROLLBACK 

Рис. 4.1. Типовая структура транзакции 

Каким образом делается проверка правильности исполнения оператора SQL и насколько глубоко она делается - определяется мастерством программиста. При этом могут учитываться возможности 
алгоритмического языка, семантика приложения, а также возможно
9 

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

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

Заметим, что возврат в исходное состояние выполняется средствами 
СУБД, 
поэтому 
в 
программе 
никаких 
связей 
между 
ROLLBACK и началом нет. 

Для дополнительного пояснения структуры транзакции приведем 
пример транзакции на псевдокоде [1], которая добавляет данные в 
столбцы S, Р, QTY таблицы SP и модифицирует данные в столбце 
TOTQTY таблицы TAB. 

Пример транзакции (псевдокод): 

BEGIN TRANSACTION ; 
INSERT INTO SP (S, P,QTY) 
VALUES ('S5', 'PI', 1000); 
IF возникла ошибка THEN GO TO UNDO ; 
UPDATE TAB 
SET TOTQTY = TOTQTY +1000 
WHERE P2 = 'РГ; 
IF возникла ошибка THEN GO TO UNDO ; 
COMMIT TRANSACTION ; 
GO TO FINISH ; 
UNDO: 

ROLLBACK TRANSACTION ; 
FINISH : 

RETURN ; 

Здесь не показана проверка исполнения операторов INSERT и 
UPDATE. Еще раз подчеркнем, что проверка может быть различной 
(однако отразить ее в псевдокоде не представляется возможным). 

10 

5. ВОЗМОЖНЫЕ СЛУЧАИ ЗАВЕРШЕНИЯ 
ТРАНЗАКЦИЙ 

Возможны четыре случая завершения транзакций [2]. Они представлены на рис. 5.1 инвариантно относительно модели транзакции. 
Поэтому в самом общем виде указано «Начало транзакции». Операторы SQL, входящие в тело транзакции, выбраны произвольно. 

Рис. 5.1. Возможные случаи завершения транзакций 

В первом случае транзакция завершается успешно, о чем свидетельствует выдача оператора COMMIT. 

Во втором случае программа успешно завершена. Однако программист по каким-то причинам (сознательно или нет) не выдал оператор COMMIT в конце транзакции. В этом случае система сама успешно завершает транзакцию. 

В третьем случае произошел сбой при выполнении транзакции, 
выдан оператор SQL ROLLBACK. СУБД откатывает транзакцию. 

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

11 

Обратим внимание на второй случай. Оператор COMMIT не выдан, но все работает нормально. Неиспользование 
оператора 
COMMIT означает, что: 

1) программист недостаточно опытен, т.е. не знает, что пишет 
транзакции (именно этот случай упоминался в разд. 3); 

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

Несмотря на то, что СУБД успешно справляется с ситуацией отсутствия оператора COMMIT, его необходимо ставить во избежание 
лишних системных затрат времени. 

6. БЛОКИРОВАНИЕ ИНФОРМАЦИОННЫХ 
ОБЪЕКТОВ БАЗЫ ДАННЫХ 

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

Его основная идея очень проста: если для выполнения некоторой 
транзакции необходимо, чтобы какой-либо объект базы данных (например, отдельный кортеж таблицы или вся таблица) не изменялся 
непредсказуемо и без ведома этой транзакции, то объект блокируется. Таким образом, эффект блокирования состоит в том, чтобы «заблокировать доступ к какому-то определенному объекту со стороны 
других транзакций», а значит, предотвратить непредсказуемое изменение этого объекта. Следовательно, первая транзакция в состоянии 
выполнить всю необходимую обработку с учетом того, что обрабатываемый объект остается в стабильном состоянии настолько долго, 
насколько это нужно. 

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

12