Сериализация транзакций

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

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

Рис. 44. Модель управляемого выполнения транзакций

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

Рис. 45. Проблема утраченного обновления

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

Рис. 46. Преждевременное чтение

Пользователь А будет предпринимать действия над ошибочными данными. Иногда для такого рода проблем используется термин преждевременное чтение.

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

Рис. 47. Фантомная вставка

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

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

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

Между транзакциями могут существовать следующие виды конфликтов:

· транзакция 2 пытается изменять объект, измененный незакончившейся транзакцией 1 (конфликт W-W, запись-запись);

· транзакция 2 пытается изменять объект, прочитанный незакончившейся транзакцией 1 (конфликт R-W, чтение-запись);

· транзакция 2 пытается читать объект, измененный незакончившейся транзакцией 1 (конфликт W-R, запись-чтение).

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

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

Тем самым, выделяются два основных режима захватов:

· совместный режим – S(Shared), означающий разделяемый захват объекта и необходимый для выполнения операции чтения объекта;

· монопольный режим – X(eXclusive), означающий монопольный захват объекта и необходимый для выполнения операций записи, удаления и модификации.

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

· фаза роста – накопление захватов (установление блокировок);

· фазафиксации или отката – освобождение захватов (снятие блокировок).

Реализуемость транзакций гарантируется, если блокировки, относящиеся к одновременно выполняемым транзакциям, удовлетворяют правилу: «Ни одна блокировка от имени какой-либо транзакции не должна устанавливаться, пока не будет снята ранее установленная блокировка».

В реляционных БД объектами для захвата могут быть:

· файл – физический (с точки зрения БД) объект, область хранения нескольких отношений и индексов;

· таблица – логический объект, соответствующий множеству записей данного отношения;

· страница данных – физический объект, хранящий записи одного или нескольких отношений, индексную или служебную информацию;

· запись – элементарный физический объект БД.

Блокировка на уровне поля не реализована, поскольку приводит к перегрузке менеджера блокировок и к падению производительности системы.

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

Очевидно, что чем крупнее объект захвата, тем меньше захватов будет поддерживаться в системе и на это будут тратиться меньшие накладные расходы. Если выбрать в качестве уровня объектов для захватов файл или отношение, то будет решена даже проблема фантомных вставок.

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

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