Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
Шрифт:
! ! !
Примечание. В базах данных, с которыми работают с помощью драйверов, не использующих двухвфазное подтверждение, таких как Borland Database Engine (BDE), никогда не возникает зависших транзакций.
. ! .
Ограниченные базы данных
Транзакции над несколькими базами данных могут использовать много ресурсов сервера. В ESQL Firebird предоставляет языковую поддержку в форме предложения USING для ограничения баз данных, к которым транзакциям разрешен доступ. DSQL не предоставляет языковую
Пессимистическая блокировка
В пессимистической блокировке СУБД строки, запрошенные одним пользователем или транзакцией для операции, которая может изменить состояние данных, немедленно становятся недоступными для чтения или записи другим пользователям или транзакциям. В некоторых системах недоступной становится целая таблица. Многие разработчики, переносящие базы данных и приложения в Firebird из подобных систем, приходят в замешательство из-за оптимистической блокировки и безнадежно отыскивают способы подражать старому.
В Firebird все изменения выполняются на уровне строки - не существует механизма блокировки отдельного столбца. Почти на всех уровнях изоляции транзакции ядро сервера осуществляет принцип оптимистической блокировки: все транзакции, не ограниченные какой-либо формой пессимистической блокировки, начинаются с просмотра текущего подтвержденного состояния всех строк во всех таблицах- конечно, при соответствующих привилегиях. Когда транзакция передает запрос на изменение строки, старая версия этой строки остается видимой всем транзакциям. Писатели не блокируют читателей.
При успешном выполнении изменения сервер внутренне создает новую версию строки, которая неявно блокирует исходную версию. В зависимости от установок этой пользовательской транзакции и других транзакций появится конфликт блокировки некоторого уровня, если другая транзакция попытается изменить или удалить заблокированную строку. Подробности об условиях блокировки Firebird см. в главе 26.
Firebird разработан для интерактивного использования многими конкурирующими пользователями; редко можно найти подлинные причины для использования пессимистической блокировки. Это не "магическая пуля", с помощью которой нужно эмулировать поведение настольных СУБД. Пессимистические блокировки одной транзакции приведут к конфликтам в других транзакциях. Нет возможности уйти от ответственности при работе с многопользовательской моделью транзакций и написании обработчиков предполагаемых конфликтов блокировки.
Блокировка на уровне таблицы
Уровень изоляции транзакции TABLE STABILITY (или согласованная изоляция) предоставляет полную блокировку таблицы по записи, включая зависимые таблицы. Этот уровень слишком агрессивен для интерактивных приложений.
Более предпочтительным является использование предложения RESERVING с уровнями изоляции READ COMMITTED и SNAPSHOT, потому что оно предоставляет больше гибкости и управляемости для таблиц, которые вы хотите заблокировать в процессе выполнения транзакции. Предложение содержит параметры, которые определяют требуемый
RESERVING <предложение -резервирования>;
<предложение-резервирования> = table [, table ...]
[FOR [SHARED f PROTECTED] {READ | WRITE}]
[, <предложение-резервирования>]
<предложение-резервирования> может включать в себя множество спецификаций резервирования наборов, предоставляя возможность резервировать различные таблицы или группы таблиц с различными правами. Конкретная таблица должна появляться только один раз в предложении резервирования. Обратитесь к предыдущей главе для получения информации о резервировании таблиц.
Блокировка на уровне оператора
Пессимистическая блокировка на уровне оператора - влияющая на индивидуальные строки или наборы - не является прямым вопросом конфигурации транзакции. При этом воздействие этих типов блокировок напрямую управляется установками транзакций в транзакции, в которой определена блокировка, и в других транзакциях, которые пытаются получить доступ к блокированной строке или набору. Это является основным решением в рамках таких техник в терминах установок транзакции.
Пессимистическая блокировка строки или набора является противоположностью того способа работы, для которого был спроектирован Firebird. Короче говоря, если вы жили с пессимистической блокировкой и зависели от нее до знакомства с Firebird, то пришло время получить удовольствие от многоверсионной архитектуры и преимуществ оптимистической блокировки строки.
При этом нельзя отрицать, что иногда требования разработки вызывают необходимость пессимистической блокировки, хотя такая потребность бывает гораздо реже, чем в случае работы с другими СУБД. Тем не менее лучшим сценарием, включающим абсолютное требование исключительного доступа к строкам, не является блокировкой на уровне таблицы. Обычно прочитанная строка должна быть защищена от изменения или удаления. Такое требование иногда называется строгой сериализацией задач.
Для случаев, когда необходима пессимистическая блокировка на уровне строки, механизм пессимистической блокировки и поддерживаемый синтаксис SQL реализованы в версии 1.5. До этого сервер Firebird по существу этого не поддерживал. В данном разделе мы сначала посмотрим на стандартный "трюк", который выполняют клиентские приложения- когда для этого отсутствует языковая поддержка для получения пессимистической блокировки. Затем мы рассмотрим синтаксис и условия явного SELECT ... WITH LOCK, который осуществляет поддержку пессимистической блокировки для SQL в Firebird 1.5.
"Редактирование" не является деятельностью на стороне сервера, следовательно, когда пользователь щелкает по кнопке Редактировать (или использует любой другой интерфейс для редактирования данных), это ничего не изменяет на сервере. Пока сервер не озабочен изменениями, транзакция просто читает. Никаких новых версий записей не создается. Не существует блокировок. Ничто не изменяется, пока пользователь не завершит редактирование строки, и приложение фактически не отправит на сервер работу пользователя.