Как сервер работает с WITH LOCK
Попытка редактирования записи с помощью оператора UPDATE
, заблокированной другой транзакцией, приводит к вызову исключения конфликта обновления или ожиданию завершения блокирующей транзакции – в зависимости от режима TPB.Поведение сервера здесь такое же, как если бы эта запись уже была изменена блокирующей транзакцией.
Нет никаких специальных кодов gdscode, возвращаемых для конфликтов обновления, связанных с пессимистической блокировкой.
Сервер гарантирует, что все записи, возвращённые явным оператором блокировки, фактически заблокированы и действительно соответствуют условиям поиска, заданным в операторе WHERE, если эти условия не зависят ни от каких других таблиц, не имеется операторов соединения, подзапросов и т.п.Это также гарантирует то, что строки, не попадающие под условия поиска, не будут заблокированы.Это не даёт гарантии, что нет строк, которые попадают под условия поиска, и не заблокированы.
Note
|
Такая ситуация может возникнуть, если в другой, параллельной транзакции подтверждаются изменения в процессе выполнения текущего оператора блокировки. |
Сервер блокирует строки по мере их выборки.Это имеет важные последствия, если вы блокируете сразу несколько строк.Многие методы доступа к базам данных Firebird по умолчанию используют для выборки данных пакеты из нескольких сотен строк (так называемый "буфер выборки"). Большинство компонентов доступа к данным не выделяют строки, содержащиеся в последнем принятом пакете, и для которых произошёл конфликт обновления.