3)Отсутствие неповторяющихся чтений (третий уровень изоляции)

Рассмотрим сценарий совместного выполнения транзакций T₁ и T₂, показанный на рис. 13.3. В момент времени t₁ транзакция T₁ читает объект базы данных o (выполняет операцию R(o)). До завершения транзакции T₁ в момент времени t₂ > t₁ транзакция T₂ изменяет объект o (выполняет операцию W(o)) и успешно завершается оператором COMMIT. В момент времени t₃ > t₂ транзакция T₁ повторно читает объект o и видит его измененное состояние.

  Рис. 13.3. Неповторяющиеся чтения

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

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

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

План выполнения транзакций называют сериальным. Если результат выполнения нескольких транзакций эквивалентен результату их последующего выполнения.

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

Сериализация выполняет предотвращение следующих конфликтов выполнения транзакций:

1. одна транзакция пытается изменить объект, изменённый другой, незакончившейся транзакцией.

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

3. Транзакция пытается читать объект ,изменённый другой, ещё незаконченной транзакцией.

Методы сериализации транзакций:

1. Метод синхронизационных захватов объектов ( самый распространённый).

2. Метод временных меток.

47. Метод синхронизационных захватов объектов.

Наиболее распространенным в централизованных СУБД (включающих системы, основанные на архитектуре "клиент-сервер") является подход, основанный на соблюдении двухфазного протокола синхронизационных захватов объектов БД. В общих чертах протокол состоит в том, что перед выполнением любой операции в транзакции T над объектом базы данных r от имени транзакции T запрашивается синхронизационный захват объекта r в соответствующем режиме (в зависимости от вида операции).

Основными режимами синхронизационных захватов являются:

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

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

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

первая фаза транзакции - накопление захватов;

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

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

В контексте реляционных баз данных возможны следующие альтернативы:

1. файл - физический (с точки зрения базы данных) объект, область хранения нескольких отношений и, возможно, индексов;

2. отношение - логический объект, соответствующий множеству кортежей данного отношения;

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

4. кортеж - элементарный физический объект базы данных.

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

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

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

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

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