В большинстве коммерческих СУБД для повышения степени параллельности доступа нескольких пользователей к одной базе данных используются блокировки различных типов. Наиболее широко распространены два из них:
• Когда транзакция извлекает информацию из базы данных, СУБД применяет нежесткую блокировку. При этом другие транзакции, выполняемые параллельно, могут извлекать те же данные.
• Когда транзакция обновляет информацию в базе данных, СУБД применяет жесткую блокировку. Если транзакция жестко заблокировала какие-либо данные, другие транзакции не могут обращаться к ним ни для выборки, ни для записи. На рисунке 30 изображены допустимые комбинации блокировок для двух параллельно выполняемых транзакций. Следует отметить, что транзакция может применять для данных жесткую блокировку только в том случае, если ни одна другая транзакция не блокирует эти данные. Если транзакция пытается осуществить блокировку, не разрешенную правилами, представленными на рисунке, ее выполнение приостанавливается до тех пор, пока другие транзакции не разблокируют необходимые ей данные.
На следующем рисунке изображены те же транзакции, что и на рисунке 29, но в них на этот раз используются жесткая и нежесткая блокировки. Если сравнить два этих рисунка, то можно увидеть, что новый механизм блокировки повышает степень параллельности доступа к базе данных.
Рисунок 30 Правила применения жесткой и нежесткой блокировок
К сожалению, применение любого механизма блокировки для поддержки параллельного выполнения транзакций приводит к возникновению проблемы, которая называется тупиковой ситуацией. На следующем рисунке изображена типичная тупиковая ситуация. Программа А обновляет таблицу ORDERS и поэтому блокирует часть этой таблицы. Тем временем программа B обновляет таблицу PRODUCTS и блокирует ее часть. Затем программа А пытается обновить таблицу PRODUCTS, а программа B пытается обновить таблицу ORDERS, причем каждая пытается обновить ту часть таблицы, которая заблокирована другой программой.
Рисунок 31 Тупик двух транзакций
Без внешнего вмешательства обе программы будут бесконечно ожидать, пока другая программа завершит транзакцию и разблокирует данные. Но могут возникнуть и более сложные ситуации, когда три, четыре или даже больше программ попадают в “цикл” блокировок и каждая из них ожидает освобождения данных, заблокированных другой программой.
Как правило, для устранения тупиковых ситуаций СУБД периодически (скажем, каждые пять секунд) проверяет блокировки, удерживаемые различными транзакциями. Если СУБД обнаруживает тупик, то произвольно выбирает одну транзакцию в качестве “проигравшей” и отменяет ее. Это освобождает блокировки, удерживаемые проигравшей транзакцией, позволяя “победителю” продолжить работу. Проигравшей программе посылается код ошибки, показывающий, что она проиграла в тупиковой ситуации и её текущая транзакция была отменена.
Такая схема устранения тупиков означает, что любая инструкция SQL может вернуть код ошибки “проигрыша в тупиковой ситуации”, хотя сама по себе инструкция будет правильной. Транзакция, пытающаяся выполнить эту инструкцию, отменяется не по вине последней, а из-за параллельной работы с базой данных многих пользователей. Такая схема может показаться несправедливой, но на практике она лучше двух возможных альтернатив: “зависания” или нарушения целостности данных. Если ошибка “проигрыша в тупиковой ситуации” происходит в интерактивном режиме, пользователь может просто повторно ввести инструкции (одну или несколько). В программном SQL прикладная программа сама должна обрабатывать код подобной ошибки. Обычно в таких случаях программа либо выдает предупреждающее сообщение пользователю, либо пытается выполнить транзакцию повторно.
Вероятность возникновения тупиков можно резко уменьшить, если тщательно планировать обновления базы данных. Все программы, которые в своих транзакциях обновляют несколько таблиц, по возможности должны всегда обновлять таблицы в одном и том же порядке. Это приводит к плавному перемещению блокировок по таблицам и сводит к минимуму возможность возникновения тупиков. Кроме того, для дальнейшего уменьшения количества возникающих тупиков можно использовать средства явной блокировки, описанные ниже.
