Intent Exclusive монопольная блокировка намерения, сокращенно IX.
Intent Share коллективная блокировка намерения, сокращенно IS.
Из возможных типов блокировок нас интересуют (здесь и далее используется терминология Microsoft SQL Server):
Чтобы наложить монопольную блокировку на страницу данных, сервер должен убедиться, что ни на одну из записей, входящих в эту страницу, никакая блокировка не наложена. То есть необходимо перебрать все записи, входящие в страницу, и проверить их на наличие блокировок. То же самое, только в гораздо большем объеме, необходимо делать и для таблицы. Это было бы достаточно дорогостоящей операцией, но тут на помощь приходят блокировки намерения. Прежде чем ставить блокировку на конкретную запись, ставится соответствующая блокировка намерения на таблицу и страницу. Таким образом, отпадает необходимость проверять все записи, достаточно проверить, есть ли блокировка намерения на соответствующем уровне иерархии.
Дело в том, что объекты в БД выстраиваются в своеобразную иерархию Таблица->Страница->Запись. Любая из вышеупомянутых блокировок может быть наложена на любой из этих объектов.
Вышеописанными тремя типами возможные типы блокировок не ограничиваются. Нас также будут интересовать так называемые «блокировки намерения» (Intent Lock)
Блокировки намерения
Update Lock это промежуточная блокировка, блокировка «обновления». Она совместима с Read Lock, но не совместима с Write Lock и сама с собой. Иными словами на один объект могут быть одновременно наложены одна блокировка обновления, ни одной монопольной блокировки и сколь угодно много коллективных блокировок. Этот тип блокировок введен как раз для снижения риска возникновения взаимоблокировки. Каким именно образом, будет объяснено ниже.
Write Lock блокировка записи, она же «монопольная», она же «эксклюзивная». Эта блокировка не совместима ни с Read Lock, ни сама с собой, ни с каким либо другим типом блокировок. То есть в один момент времени на один объект может быть наложена только одна монопольная блокировка. Эта блокировка в терминологии MSSQL называется Exclusive Lock, или же сокращенно X.
Read Lock блокировка чтения, она же «коллективная», она же «разделяемая». Смысл этой блокировки в том, что она совместима с точно такими же блокировками. Иными словами, на один и тот же ресурс может быть наложено сколь угодно много коллективных блокировок. В терминологии MSSQL эта блокировка называется Shared Lock, или сокращенно S.
Поскольку запрос может быть как на чтение, так и на запись, то блокировки для этих случаев так же отличаются, вдобавок существует еще и промежуточный тип блокировки.
ПРИМЕЧАНИЕСтоит упомянуть, что блокировка отнюдь не единственный способ обеспечить вышеупомянутую синхронизацию. В теории существует больше десятка способов, как блокировочных, так и не основанных на блокировках, а так же гибридных; версионные (multiversioning), на временных метках (timestamp), на направленных ацикличных графах (DAG), агрессивные и консервативные их варианты, и т.д.
Блокировка не может быть наложена на несколько объектов одновременно. Между наложением блокировок на два разных объекта, теоретически, может произойти что угодно, даже если эти объекты две записи в одной и той же таблице, расположенные рядом. С помощью блокировок обеспечивается синхронизация доступа к ресурсам. Под ресурсами или объектами здесь и далее будет иметься в виду какой-нибудь объект БД запись, страница данных или таблица. Синхронизация происходит благодаря тому, что прежде чем прозвести с объектом какие-то действия (прочитать или изменить), на него накладывается блокировка. Она запрещает изменять или даже читать объект другим транзакциям до тех пор, пока транзакция, наложившая блокировку, не завершит работу с этим объектом. Синхронизация доступа нужна для того, чтобы не допустить воздействия одной транзакции на другую при одновременном выполнении. Иными словами, в идеальном случае, транзакция, даже если их одновременно выполняется множество, должна дать такой же результат, как если бы она выполнялась одна, а других транзакций не было вообще. Однако следует помнить, что в большинстве серверов такой идеальный режим работы параллельных транзакций «по умолчанию» не включен. Подробнее об этом чуть ниже.
«Блокировка», в отличие от «взаимоблокировки», явление совершенно обычное, и означает лишь то, что транзакция получит некий ресурс в свое распоряжение не сразу, а чуть-чуть подождав, пока другая транзакция не снимет с этого ресурса блокировку, наложенную ранее.
Удивительно, но на форумах достаточно часто появляются вопросы, из текста которых становится ясно, что автор попросту перепутал термины «блокировка» (lock) и «взаимоблокировка» (deadlock). Во избежание подобных недоразумений начнем с самого начала.
Разговор о взаимоблокировках сложно вести, не располагая некоторой базовой терминологией. Здесь я попытаюсь изложить необходимый минимум основных понятий и терминов. Эта часть никоим образом не претендует на полноту, поэтому в случае возникновения каких-либо вопросов рекомендую обратиться к литературе упомянутой ниже. Те же, кто в блокировках, как таковых, разбирается в достаточной степени, могут смело пропустить этот раздел.
Основные понятия
Проблема взаимоблокировок в реальном приложении может привести к порче достаточно большого количества нервных клеток, и в то же время довольно скудно описана. Цель данной статьи хотя бы отчасти восполнить этот досадный пробел и объяснить, что такое взаимоблокировки и как с ними бороться. В качестве подопытной свинки выбран Microsoft SQL Server, однако теоретическая часть также относится и к другим серверам баз данных, хотя бы отчасти применяющим блокировочный механизм для обеспечения корректности параллельной обработки транзакций, например, DB2, Oracle, Informix и даже Interbase.
DeadlocksЧто такое взаимоблокировки и как с ними бороться Автор: Источник: Опубликовано: 05.05.2004Исправлено: 15.04.2009Версия текста: 1.0 Введение
Deadlocks P PP PP P PP PP PPPОценить P
Комментариев нет:
Отправить комментарий