Книга: Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Блокировка на уровне оператора

Блокировка на уровне оператора

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

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

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

Для случаев, когда необходима пессимистическая блокировка на уровне строки, механизм пессимистической блокировки и поддерживаемый синтаксис SQL реализованы в версии 1.5. До этого сервер Firebird по существу этого не поддерживал. В данном разделе мы сначала посмотрим на стандартный "трюк", который выполняют клиентские приложения- когда для этого отсутствует языковая поддержка для получения пессимистической блокировки. Затем мы рассмотрим синтаксис и условия явного SELECT ... WITH LOCK, который осуществляет поддержку пессимистической блокировки для SQL в Firebird 1.5.

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

Разработчики, которые рассматривают такое поведение как сложную проблему, обманывают ситуацию, пересылая в своих приложениях "фиктивное изменение" строки, когда пользователь запрашивает ее редактирование. "Трюк" заключается в том, что оператор изменения устанавливает значение столбца в его текущее значение. Обычно используется столбец первичного ключа, например:

UPDATE ATABLE

SET PKEY = PKEY

WHERE PKEY = PKEY;

Следовательно, сервер создает новую версию записи, в которой нет никаких отличий от последней подтвержденной версии, и задает блокировку этой строки. Когда пользователь сообщает, что он завершил редактирование строки, приложение посылает на сервер реальное изменение, например:

UPDATE ATABLE

SET COLUMN2 = 'Некоторое новое значение',

C0LUMN3 = 99,

. . .

WHERE PKEY = <значение первичного ключа>;

На сервер пересылается еще одна новая версия записи, перекрывая первую.

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

! ! !

ВНИМАНИЕ! Если вы используете эту технику, убедитесь, что триггеры условий BEFORE UPDATE и BEFORE DELETE, относящиеся к тем таблицам, которые используются в фиктивных изменениях, не помешают выполнению необходимых действий.

. ! .

! ! !

СОВЕТ. Может оказаться необходимым создание в вашей таблице специального скрытого столбца FLAG для специфического использования в качестве флага фиктивных изменений. Например, скрытый столбец типа данных INTEGER может увеличиваться на единицу вашим оператором, выполняющим фиктивное изменение. Тогда в триггерах можно задать выполнение "реальных" изменений только в случае IF (NEW.FLAG <> OLD.FLAG).

. ! .

Не рекомендуется изменять одну и ту же строку более одного раза в одной транзакции, потому что это будет пересекаться как с автоматической целостностью данных (ссылочная целостность), так и с пользовательскими триггерами. Когда используются точки сохранения (savepoint), это приводит к сильному росту количества версий записей. Такое дублирование обычно является следствием небрежного проектирования логики приложения. При этом "дважды измененное изменение" является точной целью техники "фиктивных изменений". Если в этих транзакциях не используются точки сохранения, а в триггерах производится проверка на реальные изменения, все будет в безопасном состоянии.

Синтаксис явной блокировки:

SELECT спецификация-выхода FROM имя-таблицы

[WHERE условие-поиска]

[FOR UPDATE [OF столбец1 [, столбец2 [, ...]]]]

WITH LOCK;

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

Поведение ожидания и сообщение о конфликте зависят от параметров транзакции, заданных в буфере параметров транзакции (TPB).

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

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

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

Если указано SELECT ... WITH LOCK и необязательное предложение FOR UPDATE опущено, то все строки в наборе будут предварительно заблокированы, неважно, изменяете вы их фактически или нет. При аккуратном конфигурировании транзакции и управлении буферизацией со стороны клиента блокировка будет предотвращать доступ по записи к любой из этих строк или к зависимым от них строкам другим транзакциям, пока не завершится ваша транзакция. Предварительная блокировка набора, содержащего много строк, приведет к росту конфликтов блокировок, и ваш код приложения должен быть готовым к их обработке.

Таблица 27.3. Взаимодействие установок транзакции и явных блокировок

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

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

SELECT * FROM DOCUMENT

WHERE ID = ? WITH LOCK /* ID - первичный ключ */

Необязательное предложение FOR UPDATE предоставляет способ для определения набора из множества строк, загрузки и обработки строк за один раз.

Если присутствует предложение FOR UPDATE, буферизованная загрузка будет отключена, а блокировка будет применяться к каждой строке, одна за другой в том порядке, в котором они загружаются из кэша с серверной стороны. Если именованный курсор[108] управляет позицией обновления, это предложение может включать необязательное выражение ON <список-столбцов> для направления изменений указанным столбцам курсора.

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

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

SELECT + FROM DOCUMENT

WHERE PARENT FOR UPDATE WITH LOCK

Конструкция SELECT ... WITH LOCK доступна в DSQL и PSQL. Она может использоваться только в операторе SELECT верхнего уровня для единственной таблицы.

* Она недоступна в подзапросе или в соединяемом наборе.

* Она не может быть указана с квантификаторами (оператор DISTINCT, FIRST или SKIP), С предложением GROUP BY, а также с любыми другими агрегатными операциями.

* Она не может быть использована в просмотрах, во внешних таблицах и в выходном наборе хранимой процедуры выбора.

Оглавление книги