Распределенные транзакции

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

СУБД для работы с менеджерами ресурсов используют transaction manager (TM), который в SQL Server 200 называется MS Distributed Transaction Coordinator (MS DTS), удовлетворяющий спецификации X/OPEN XA.

Любой менеджер транзакций использует протокол двухфазной фиксации изменений.

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

Распределенные транзакции стартуют, если:

1) в запросе явно используется несколько баз данных;

2) приложение начинает локальную транзакцию, из которой вызывается удаленная хранимая процедура. Если параметр базы данных REMOTE_PROC_TRANSACTION установлен в ON, то локальная транзакция автоматически расширяется до распределенной;

3) приложение начинает распределенную транзакцию, используя методы OLE DB или ODBC;

4) сервер встречает команду BEGIN DISTRIBUTED TRANSACTION, для завершения/отката которой используются стандартные команды ROLLBACK и COMMIT .

Поведение сервера для всех открываемых соединений регулируется таким образом:

EXEC sp_configure ’remote proc trans’ {0 | 1}

В рамках отдельного соединения можно перекрыть настройки сервера, изменив параметр

SET REMOTE_PROC_TRANS {ON | OFF}

Несколько общих правил работы с транзакциями:

1. Придерживаться одного стиля управления транзакциями: либо – все вызывается явно, либо – все вызывается неявно.

2. Придерживаться одного механизма обращения к данным:

Библиотеки OLE DB и ADO поддерживают методы явного манипулирования транзакциями. В протоколе ODBC явное манипулирование транзакциями невозможно, ODBC поддерживает только неявное или автоматическое определение транзакции.

Пример: Транзакция стартовала через ODBC-драйвер, а завершение ее было выполнено явно – с помощью ROLLBACK. Драйвер ODBC не получает информации о закрытии транзакции, что приводит в ошибке.

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

Существует особый вид транзакций, называемых «вложенными»(nested) транзакциями.

Вложенная транзакция – транзакция, выполнение которой инициируется из тела уже активизированной транзакции. Основное применение вложенных транзакций заключается в поддержке транзакций, выполняемых хранимыми процедурами.

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

Закрытие транзакций происходит снизу вверх, т.е. первая команда COMMIT(ROLLBACK) закрывает самую нижнюю транзакцию. В случае отката на любом уровне вложенности разрешается указать имя только самой верхней транзакции, таким образом, откатываются все транзакции, вплоть до самой верхней. Если же требуется откатить часть транзакций, то используется команда

SAVE TRAN[SACTION]

{savepoint_name | @savepoint_var}

где savepoint_name (имя точки сохранения) следует указывать явно.

Это имя затем можно указывать в ROLLBACK для определения места отката.

Сформулируем общие рекомендации при разработке кода транзакций:

1. выполнять действия по обработке данных в одном и том же порядке обращения к ресурсам

2. избегать в теле транзакции взаимодействия с пользователем

3. минимизировать число действий в транзакции (избегать длинных транзакций), которые провоцируют и сетевые потери от открытых соединений

4. использовать как можно более низкий уровень изоляции

5. использовать связанные соединения (bounded connections): если одно приложение устанавливает несколько соединений с сервером, и обрабатывает одни и те же данные, то при использовании связанных соединений блокировки, установленные второстепенными соединениями, рассматриваются как установленные главным соединением, следовательно, не возникает конфликтов блокирования.