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

Как уже упоминалось, установка Х- и S-блокировок имеет смысл как для отдельных кортежей, так и для переменных-отношений в целом. В соответствии с [15.8] и [15.9] можно ввести три типа блокировки намерения, которые имеют смысл для переменных-отношений в целом, но не для отдельных кортежей: разделяемая блокировка намерения (Intent Shared - IS), эксклюзивная блокировка намерения (Intent exclusive - IX) и разделяемая эксклюзивная блокировка намерения (Shared Intent eXclusive - SIX). Ниже приводятся неформальные определения всех этих видов блокировок (предполагается, что транзакция Т устанавливает блокировку рассматриваемого типа для переменной-отношения R), причем для полноты изложения приводятся также определения S- и Х-блокировок.

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

1Х-блокировка. В дополнение к действиям, описанным выше в определении IS-блокировки, транзакция Т сможет обновлять отдельные кортежи переменной-отношения R и, следовательно, устанавливать для них Х-блокировки.

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

SIX-блокировка. В определении этой блокировки комбинируются возможности S- и 1Х-блокировок, т.е. транзакция Т допускает параллельное считывание данных из переменной-отношения R, но запрещает их обновление. В дополнение к этому транзакция Т имеет право обновлять отдельные кортежи переменной-отношения R, для которых устанавливаются Х-блокировки.

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

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

Puc. 15.11. Матрица совместимости, расширенная блокировками намерения

Теперь можно дать более точную формулировку протокола блокировки намерения.

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

2. Прежде чем некоторой транзакции будет разрешено сделать запрос на установку X-блокировки для определенного кортежа, она должна установить либо IX-блокировку, либо блокировку более сильного типа (см. ниже) для той переменной-отношения, в которой данный кортеж содержится.

(Однако следует отметить, что это все еще далеко не полное определение. Подробности можно найти в комментарии к [15.9].)

Упомянутое в приведенном выше определении понятие относительной силы блокировок можно пояснить с помощью диаграммы приоритетов, представленной на рис. 15.12. Блокировка типа L2 называется более сильной (т.е. находится на диафамме приоритета выше) по отношению к блокировке типа L1 тогда и только тогда, когда в мафице совместимости для любой конфликтной ситуации (N), отмеченной в некоторой сфоке столбца блокировки типа L1, пометка (N) присутствует в той же сфоке столбца блокировки типа L2

(см. рис. 15.11). Обратите внимание на то, что запрос установки блокировки, который отвергается некоторым типом блокировки, обязательно будет отвергнут и более сильным типом блокировки (таким образом, неявно подразумевается, что всегда можно использовать более сильные типы блокировки вместо того типа, который сфого необходим в данном конкретном случае). Обратите внимание, что ни S-, ни 1Х-блокировки не являются более сильными по отношению одна к другой.

Стоит отметить, что на практике блокировки уровня переменных-отношений, требуемые протоколом блокировки намерения, как правило, устанавливаются неявным образом. Например, для транзакции, выполняющей только операции чтения, система может неявно установить IS-блокировку для каждой переменной-отношения, к которой данная транзакция обращается. Однако для фанзакций обновления, вероятно, потребуется установить уже 1Х-блокировки. Тем не менее в системе также должна быть предусмотрена возможность явной установки блокировок с помощью раз-

Рис. 15.12. Диаграм.ма приоритета различных типов блокировки

ного рода операторов блокировки (LOCK). Это позволит транзакциям в случае необходимости явно устанавливать S-, Х- и SIX-блокировки на уровне переменных-отношений. Например, подобный оператор явной установки блокировок поддерживается СУБД DB2 (хотя это и не требуется стандартом языка SQL).

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

15.9. Средства языка SQL

в стандарте языка SQL не предусмотрена явная поддержка каких-либо функций блокировки (фактически понятие блокировки в нем вообще не упоминается). Однако реализация подобньг>( средств необходима для получения гарантий исключения конфликтньг>( ситуаций между транзакциями, вьтолняющимися параллельно. Точнее говоря, требуется, чтобы обновления, выполняемые некоторой транзакцией Т1, не были доступны любой другой транзакции Т2 до тех и обязательно до тех пор, пока не будет завершено выполнение транзакции Т1. Фиксация транзакции открывает доступ ко всем обновлениям, выполненным данной транзакцией. Откат транзакции приводит к тому, что все выполненные ею обновления отменяются.

Замечание. Сказанное выше относится к случаю, когда все транзакции выполняются на уровне изоляции READ COMMITTED (чтение зафиксированного), REPEATABLE READ (повторяемое чтение) и SERIALIZABLE (упорядочиваемость). К транзакциям, выполняемым на уровне изоляции READ UNCOMMITTED (чтение незафиксированного), применяются особые соглашения, допускающие некорректное чтение (об этом речь идет ниже), но только в режиме READ ONLY (только чтение); подробности приводятся в главе 14.

Уровни ИЗОЛЯЦИИ

В главе 14 уже упоминался оператор языка SQL SET TRANSACTION, предназначенный для указания определенных характеристик запускаемой на выполнение транзакции. Одной из таких характеристик является уровень изоляции. Существуют следующие уровни изоляции: READ COMMITTED (чтение зафиксированного), REPEATABLE READ (повторяемое чтение) и SERIALIZABLE (упорядочиваемость). По умолчанию устанавливается уровень SERIALIZABLE, однако, если задан один из трех остальных уровней, при реализации всегда можно использовать более высокий уровень, где выражение более высокий подразумевает следующее соотношение уровней: SERIALIZABLE > REPEATABLE READ > READ COMMITTED > READ UNCOMMITTED.

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