Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

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

UPDATE ATABLE

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

C0LUMN3 = 99,

. . .

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

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

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

! ! !

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

. ! .

! ! !

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

. ! .

О "дважды выполненных" изменениях

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

Явная блокировка в версии 1.5 и более поздних

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

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

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

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

WITH LOCK;

Как это работает

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

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

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

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

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

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

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