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

Транзакция А

12 01

СУБД

Транзакция В

UPDATE ORDERS

12 03

SELECT . . . FROM OFFICES

12 05 Ч

UPDATE ORDERS

12 06

UPDATE OFFICES

12 or

COMMIT

жесткая блокировка для А

ОК разблокирована разблокирована

PRODUCTS

жесткая блокировка для 8

UPDATE PRODUCTS

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

12 02

12 04

SELECT. . . FROM OFFICES

12 05

COMMIT

Рис. 12.12 Использование жесткой и нежесткой блонировок

Тупиковые ситуации *

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

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

Транзакция А

1201 ▼

СУБД

Транзакция В

UPDATE ORDERS

12 03

UPDATE PRODUCTS

ORDERS

PRODUCTS

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

жесткая блокировка для А

ожидание

жесткая блокировка для В

ожидание

12 02

UPDATE PRODUCTS

12 04

UPDATE ORDERS

Рис. 12. J 3. Тт двух транзакция

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

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

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

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

Усовершенствованные методы блокировки *

Во многих коммерческих СУБД предлагаются усовершенствованные средства блокировки, которые гораздо лучше стандартных К таким средствам относятся:

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

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

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

Явная блокировка *

Если профамма обращается к таблице многократно, затраты, связанные с блокировкой большого количества маленьких участков таблицы, могут оказаться значительными. Например, профамма пакетного обновления, которая обращается к каждой строке таблицы, в процессе работы бдет блокировать таблицу по частям. Для более быстрого выполнения фанзакции такого типа пpoфa.vшe следует явно заблокировать всю таблицу, выполнить все необходимые обновления, а затем разблокировать ее. Блокировка всей таблицы имеет три преимущества:

она усфаняет зафаты, связанные с блокировкой строк (сфаниц);

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

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

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