В представленном ниже списке перечислены доступные режимы блокировок и контексты, в которых они автоматически используются компонентом Digital Q.DataBase. Любую из этих блокировок также можно получить явно с помощью команды LOCK. Следует учитывать, что все эти режимы блокировок являются блокировками уровня таблицы, даже если в их названии содержится слово «строка»; названия режимов блокировок являются исторически сложившимися. В некоторой степени эти названия отражают типичное использование каждого режима — однако их семантика идентична. Единственное реальное различие между одним режимом блокировки и другим заключается в наборе режимов блокировок, с которыми каждый из них конфликтует (см. Таблица 2.10.2). Две транзакции не могут одновременно удерживать блокировки конфликтующих режимов на одной таблице. (При этом транзакция никогда не конфликтует сама с собой. Например, она может сначала получить ACCESS EXCLUSIVE блокировку, а затем — ACCESS SHARE блокировка той же таблицы.) Неконфликтующие режимы блокировок могут удерживаться одновременно множеством транзакций. Следует отметить, что некоторые режимы блокировок являются самоконфликтующими (например, ACCESS EXCLUSIVE блокировка не может удерживаться более чем одной транзакцией одновременно), в то время как другие не являются самоконфликтующими (например, ACCESS SHARE блокировка может удерживаться несколькими транзакциями).

После получения блокировка обычно удерживается до завершения транзакции. Однако если блокировка получена после создания точки сохранения, она немедленно снимается при откате к этой точке. Это согласуется с принципом, согласно которому ROLLBACK отменяет все эффекты команд, выполненных после точки сохранения. То же самое относится к блокировкам, полученным внутри PL/pgSQL блока исключений: выход из блока при возникновении ошибки освобождает блокировки, полученные внутри него.

Помимо блокировок на уровне таблиц, существуют блокировки на уровне строк, которые перечислены ниже вместе с контекстами, в которых они автоматически используются в Digital Q.DataBase. См. Таблица 2.10.3 для получения полной таблицы конфликтов блокировок на уровне строк. Обратите внимание на то, что транзакция может удерживать конфликтующие блокировки одной и той же строки даже в разных подтранзакциях; однако во всех остальных случаях две транзакции не могут одновременно удерживать конфликтующие блокировки одной строки. Блокировки на уровне строк не влияют на выполнение запросов данных; они блокируют только процессы записи и блокировки к той же строке. Блокировки на уровне строк освобождаются при завершении транзакции или при откате к точке сохранения, аналогично блокировкам на уровне таблиц.

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

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

Использование явного блокирования может повысить вероятность возникновения взаимные блокировки, при которой две (или более) транзакции удерживают блокировки, необходимые друг другу. Например, если транзакция 1 запрашивает исключительную блокировку таблицы A, а затем пытается получить исключительную блокировку таблицы B, в то время как транзакция 2 уже заблокировала таблицу B в исключительном режиме и теперь запрашивает исключительную блокировку таблицы A, ни одна из них не сможет продолжить выполнение. Digital Q.DataBase автоматически обнаруживает ситуации взаимной блокировки и разрешает их путем прерывания одной из задействованных транзакций, позволяя остальным завершиться. (Предсказать, какая именно транзакция будет прервана, сложно, поэтому не следует полагаться на конкретный выбор).

Следует отметить, что взаимные блокировки могут также возникать в результате блокировок на уровне строк (таким образом, они возможны даже без использования явного блокирования). Рассмотрим случай, в котором две параллельные транзакции изменяют таблицу. Первая транзакция выполняет команду:

UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 11111;

При этом запрашивается блокировка на уровне строк для строки с указанным номером счета. Затем выполняется вторая транзакция:

UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 22222;
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 11111;

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

UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;

Первая транзакция пытается получить блокировку на уровне строк для указанной строки, но это невозможно, так как вторая транзакция уже удерживает такую блокировку. Вследствие этого она ожидает завершения второй транзакции. Таким образом, первая транзакция блокируется второй, а вторая транзакция — первой: возникает состояние взаимной блокировки. Digital Q.DataBase обнаружит данную ситуацию и прервет одну из транзакций.

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

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

Digital Q.DataBase предоставляет средства для создания блокировок, значение которых определяется на уровне приложения. Такие блокировки называются рекомендательными блокировками, поскольку система не контролирует их использование — корректность их применения полностью возлагается на приложение. Рекомендательные блокировки могут быть полезны для стратегий блокирования, которые трудно реализовать в рамках модели MVCC. Например, рекомендательные блокировки часто используются для эмуляции стратегий пессимистической блокировки, характерных для так называемых «систем на основе плоских файлов» управления данными. Хотя для этой же цели можно было бы использовать флаг, хранящийся в таблице, метод рекомендательных блокировок работает быстрее, позволяет избежать раздувания таблиц и автоматически очищается сервером по завершении сеанса.

Существует два способа получить рекомендательную блокировку в Digital Q.DataBase: на уровне сеанса или на уровне транзакции. Рекомендательная блокировка, полученная на уровне сеанса, удерживается до тех пор, пока она не будет явно снята или пока не завершится сеанс. В отличие от стандартных запросов на блокировку, запросы на рекомендательную блокировку уровня сеанса не учитывают семантику транзакций: блокировка, полученная в транзакции, которая впоследствии была отменена, все равно будет удерживаться после отката; аналогично, снятие блокировки остается в силе, даже если вызвавшая его транзакция завершается ошибкой. Блокировка может быть получена владеющим процессом многократно; каждый выполненный запрос на блокировку должен сопровождаться соответствующим запросом на разблокировку, прежде чем блокировка будет фактически снята. Запросы на блокировку уровня транзакции, напротив, ведут себя аналогично обычным запросам: они автоматически снимаются по завершении транзакции, и для них не предусмотрена операция явного снятия блокировки. Данный механизм часто оказывается более удобным для краткосрочного использования рекомендательной блокировки, чем поведение на уровне сеанса. Запросы на получение блокировок на уровне сеанса и на уровне транзакции для одного и того же идентификатора рекомендательной блокировки будут блокировать друг друга ожидаемым образом. Если сеанс уже удерживает определенную рекомендательную блокировку, последующие запросы от него всегда будут успешными, даже если получения этой блокировки ожидают другие сеансы; Данное утверждение верно независимо от того, относятся ли существующая удерживаемая блокировка и новый запрос к уровню сессии или к уровню транзакции.

Как и в случае со всеми блокировками в Digital Q.DataBase, полный список рекомендательных блокировок, удерживаемых в настоящее время всеми сеансами, можно найти в pg_locks system view.

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

В определенных случаях при использовании методов рекомендательных блокировок, особенно в запросах, включающих явную сортировку и LIMIT конструкциями, необходимо контролировать получение блокировок из-за порядка, в котором вычисляются SQL-выражения. Например:

SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100; -- danger!
SELECT pg_advisory_lock(q.id) FROM
(
  SELECT id FROM foo WHERE id > 12345 LIMIT 100
) q; -- ok

В приведенных выше запросах вторая форма опасна, так как LIMIT не гарантируется применение ограничения до выполнения функции блокировки. Это может привести к установке блокировок, которые приложение не ожидало и, следовательно, не сможет освободить (до завершения сеанса). С точки зрения приложения такие блокировки будут «зависшими», хотя они по-прежнему отображаются в pg_locks.

Функции, предназначенные для управления рекомендательными блокировками, описаны в Раздел 2.6.28.10.