28. Двухфазная блокировка

Транзакция выполняется по протоколу двухфазной блокировки,

если в ней все операции блокирования предшествуют первой операции

разблокирования.

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

установку дополнительных необходимых ей блокировок. Однако она не

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

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

или для записи, в зависимости от типа требуемого доступа.

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

уже не имеет права затребовать блокировки новых элементов.

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

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

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

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

Использование протокола двухфазной блокировки для устранения проблемы зависимости от нефиксированного результата

Способ устранения проблемы зависимости от нефиксированных результатов транзакций продемонстрирован в таблице. Во избежание возникновения данной ошибки транзакция Т4 должна предварительно установить блокировку счета balх для записи. Далее она может считать из базы данных текущее значение этого счета, увеличить его на 100 единиц, а затем записать новое значение в базу данных. При выполнении отката этой транзакции выполненное ею обновление значения счета balх будет отменено и этому элементу данных будет возвращено прежнее значение, равное 100 единицам. В момент начала транзакции Т3 она также потребует установить блокировку счета balх для записи. Однако, поскольку этот элемент данных уже будет заблокирован транзакцией Т4 , запрос транзакции Т3 удовлетворить не удастся и она будет переведена в состояние ожидания вплоть до освобождения транзакцией Т4 необходимого ей элемента данных. Это произойдет только после отката результатов выполнения транзакции Т4 и приведения базы данных в исходное состояние.

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

Использование протокола двухфазной блокировки для устранения проблемы несогласованной обработки

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

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

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

29. Откат транзакции (Каскадный откат??)

Каскадный откат.

Рассмотрим график, представленный в следующей таблице, включающий выполнение трех транзакций в полном соответствии с требованиями протокола двухфазной блокировки. Транзакция Т14 выполняет блокировку счета balx для записи, после чего суммирует его текущее значение с текущим значением счета baly, для которого устанавливается блокировка для чтения. Полученное новое значение заносится в 6азу данных на счет balx после чего блокировка этого элемента данных отменяется. Затем транзакция Т15 устанавливает блокировку счета balx для записи, считывает его текущее значение из базы данных, изменяет его и записывает новое значение в базу данных, после чего отменяет блокировку этого счета. Наконец, транзакция

Т16 устанавливает блокировку счета balx для чтения и считывает из базы данных его текущее значение. В этот момент происходит отказ в работе транзакции Т14 , в результате которого выполняется ее откат. Однако, поскольку транзакция Т15 зависит от результатов транзакции Т14 (она считывала значение, которые было обновлено транзакцией Т14) для нее также необходимо выполнить откат. Аналогично, транзакция Т16 зависит от результатов транзакции Т15 и тоже должна быть отменена с выполнением отката. Подобная ситуация, в которой отмена единственной транзакции приводит к целой серии откатов зависящих от нее транзакций, называется каскадным откатом.

Пример кacкaдногo отката при использовании протокола двухфазной

блокировки

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

В подобном случае продемонстрированная в последнем примере проблема никогда не возникнет, поскольку транзакция Т15 не сможет установить требуемую ей блокировку для записи, пока транзакция Т14 не завершит свою работу тем или иным образом. Этот вариант протокола называют строгим 2PL. Может быть доказано, что при использовании строго протокола двухфазной блокировки транзакции могут быть расположены в том порядке, в котором они завершают свою работу. Другой вариант протокола 2PL, называемый ограниченным 2PL, предусматривает откладывание ДО конца транзакции освобождение только блокировок для записи. В большинстве СУБД реализуется один из этих двух вариантов протокола 2PL.

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

Кроме того, транзакции могут входить в состояние бесконечного ожидания (самоблокировки), не имея возможности установить требуемую

им новую блокировку, хотя СУБД не будет фиксировать состояния взаимной

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

по схеме "первым пришел, первым обслуживается".