Читать интересную книгу Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

Процесс выполнения транзакции

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

Вложенные транзакции

В Firebird транзакции всегда запускаются и завершаются клиентом. Некоторые другие СУБД могут запускать и подтверждать транзакции из хранимых процедур, потому что для управления транзакциями они используют двухфазную блокировку транзакций. Вместо этого Firebird предоставляет другие механизмы, которые могут оперировать с потоком работы в транзакции без нарушения атомарности. Два из этих механизмов, блоки обработчика исключений и выполняемые строки, ограничены по использованию только в модулях PSQL и обсуждаются в части VII. Другим механизмом, недоступным в PSQL, являются пользовательские точки сохранения.

Рис. 27.1. Взаимодействие приложения и транзакции

! ! !

ПРИМЕЧАНИЕ. Выполняемые строки и пользовательские точки сохранения являются новыми возможностями, добавленными в язык в Firebird 1.5.

. ! .

Пользовательские точки сохранения

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

Создание пользовательских точек сохранения

Пользовательские точки сохранения являются операцией клиентской стороны, доступной только в операторах DSQL.

Оператором создания пользовательской точки сохранения является:

SAVEPOINT <идентификатор>;

Идентификатор может быть любым правильным идентификатором SQL Firebird (максимум 31 алфавитно-цифровой символ ASCII, уникальный в транзакции). Вы можете заново использовать тот же идентификатор в той же транзакции, он перекроет существующую точку сохранения, связанную с этим именем.

Возврат на точку сохранения

Возврат (или откат, rollback) на точку сохранения начинается с отмены всей работы, выполненной и отправленной в базу данных после создания этой точки сохранения. Указанная точка сохранения и все предшествующие ей сохраняются. Любые точки сохранения, которые были созданы после указанной точки сохранения, пропадают.

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

Вот шаблон синтаксиса для отката на точку сохранения:

ROLLBACK [WORK] ТО [SAVEPOINT] <идентификатор>;

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

Освобождение точек сохранения

Механизм реализации точек сохранения на сервере - протокол в памяти - может требовать значительного количества ресурсов, особенно если одни и те же строки изменяются многократно в процессе выполнения задачи. Ресурсы уже ненужных точек сохранения могут быть освобождены при использовании оператора RELEASE

SAVEPOINT:

RELEASE SAVEPOINT <идентификатор> [ONLY];

Без ключевого слова ONLY указанная точка сохранения и все точки сохранения, которые были созданы после нее, будут освобождены и потеряны. Используйте ONLY для освобождения только указанной точки сохранения.

Следующий пример иллюстрирует работу точек сохранения:

CREATE TABLE SAVEPOINT_TEST (ID INTEGER);

COMMIT;

INSERT INTO SAVEPOINT_TEST

VALUES(99);

COMMIT;

INSERT INTO SAVEPOINT_TEST

VALUES(100) ;

/**/

SAVEPOINT SP1;

/**/

DELETE FROM SAVEPOINT_TEST;

SELECT * FROM SAVEPOINT_TEST; /* не вернет ничего */

/**/

ROLLBACK TO SP1;

/**/

SELECT * FROM SAVEPOINT_TEST; /* вернет 2 строки */

ROLLBACK;

/**/

SELECT * FROM SAVEPOINT_TEST;

/* вернет одну подтвержденную строку */

Внутренние точки сохранения

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

Когда объем изменений, выполненных перед точкой сохранения на уровне транзакции, становится большим - в пределах от 10 000 до 1 миллиона строк - ядро сервера прекращает использовать протокол автоотмены и получает ссылки напрямую из глобального образа состояния транзакции (TSB). Если у вас есть транзакция, в которой цы предполагаете выполнение операции с большим количеством изменений, отключение ведения протокола автоотмены предотвратит утечку потребляемых ресурсов, которая появится, если ваш сервер решит отменить ведение протокола. Подробности см. в разд. "Протокол автоотмены" ранее в этой главе.

PSQLРасширения для обработки исключений

Эквивалентом точек сохранения в модулях PSQL является обработка исключений. Каждый блок PSQL для обработки исключений также ограничен автоматической системой точек сохранения. Расширения PSQL предоставляют языковую оболочку для реализации того же типа вложенности транзакций, что и пользовательские точки сохранения в DSQL. Подробности см. в главе 32.

Логический контекст

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

С пользовательской точки зрения "задача" не ограничена операторами START TRANSACTION и COMMIT. Его задача имеет начало, середину и окончание, что может включать множество транзакций. Например, ошибки при пересылке или подтверждении оператора повлекут за собой откат для завершения физической транзакции. Некоторые виды вмешательств могут привести к завершению логической задачи или в нормальном случае потребуют другой физической транзакции для завершения логической задачи.

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

Подводя итог, логическая задача - это то, что мы как разработчики должны проектировать и к чему обращаться - почти всегда выходит за пределы границ START TRANSACTION и COMMIT. Физическая транзакция при этом является частью логического контекста.

Двумя ключевыми факторами в отношении логического контекста транзакции являются:

* как сохранять физический контекст начальной транзакции после ROLLBACK, чтобы работа пользователя не пропала, когда сервер отменит доступ;

* что делать, если поток работы будет прерван исключением - как диагностировать исключение и как его скорректировать.

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