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

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

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

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

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

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

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

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

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

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

Транзакция завершается, когда клиентское приложение подтверждает ее или отменяет. Если оператор COMMIT или вызов эквивалентной функции API isc_commit_ transaction не будут успешными, то транзакция не будет подтверждена. Если транзакция, которая не может быть подтверждена, не будет отменена явным вызовом клиентом ROLLBACK (ИЛИ функцией API isc_roiiback_transaction), транзакция не будет отменена. Эти операторы не являются силлогизмом. Ошибки при завершении транзакций являются весьма общей проблемой, часто обсуждаемой в публичных конференциях!

Синтаксис оператора COMMIT:

COMMIT [WORK] [RETAIN [SNAPSHOT]];

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

Необязательное расширение RETAIN [SNAPSHOT] оператора COMMIT приводит к тому, что сервер сохраняет "образ" контекста физической транзакции и производит запуск новой транзакции как клона подтвержденной транзакции. Если это так называемое мягкое подтверждение используется в транзакциях SNAPSHOT или SNAPSHOT TABLE STABILITY, клонируемая транзакция при своем запуске сохраняет тот же образ данных, что и исходная транзакция.

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