Метод двухфазного завершения транзакций

Если распределенная СУБД поддерживает распределенные транзакции, то она должна соблюдать правило все или ничего , обязательное для SQL-транзакций. Пользователь распределенной СУБД ожидает, что завершенная транзакция будет завершена во всех системах, где располагаются данные, и отмененная транзакция также будет отменена во всех системах. Кроме того, сбои в сети или в одной из систем должны приводить к тому, что СУБД прекратит выполнение транзакции и отлгенит ее, а не оставит транзакцию в частично завершенном состоянии.

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

Чтобы понять, почему необходим специальньп ! механизм двухфазного завершения, рассмотрим базу данных, представленнуго на рис. 22.13. Пользователь, находящийся в системе А, обновил одну таблицу в системе В и одну таблицу в системе С и хогел бы теперь завершить транзакцию. Предположим, что СУБД в системе А пытается завершить транзакцию, просто посьшая инструкцию commit в систему В и систему С, а затем ожидая подтверждающих ответов. Такой метод работает до тех пор, пока обе системы В и С успешно вьшолняют свои части транзакции. Но что произойдет, если, например, неисправность диска или тупиковая ситуация не позволят системе С выполнить запрашиваемые действия? Система В завершит свою часть транзакции и пошлет в систему А подтверждение, система С вследствие ошибки отменит свою часть транзакции и пошлет в систему А сообщение об ошибке, а пользователь останется с частично завершенной и частично отмененной транзакцией. Обратите внимание на то, что теперь система А не может передумать и дать системе В команду отменить фанзакцию. Транзакция в системе В завершилась, и другие пользователи, опираясь на ее результаты, возможно, уже модифицировали какие-то данные.

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

1. Профамма в системе А выдает инсфукцию commit, чтобы завершить текущую (распределенную) фанзакцию, которая обновила таблицы в системах В и С. Система .А, действует как координатор процесса завершения, согласовывая свои действия с система.ми В и С.

2. Система А посылает сообщение сет ready в системы В и С и делает отметку об этом в своем журнале фанзакции.

3. Когда СУБД в системе В или С получает сообщение get ready, она должна приготовиться либо к завершению, либо к отмене текущей транзакции. Если СУБД может перейти в состояние готова завершить , она отвечает yes системе А и отмечает этот факт в своем локальном журнале транзакций; если она не может перейти в это состояние, то отвечает n0.

4. Система А ожидает ответов на свое сообщение get ready. Если все ответы будут yes, система А посылает инстр}тшию commit в системы В и С, делая отметку об этом в своем журнале фанзакции. Если хотя бы один из ответов будет n0 или если все ответы не будут получены в течение определенного промежутка времени,

то система А посылает в обе другие системы инструкцию rollback и делает отметку об этом в своем журнале транзакций.

5. Когда СУБД в системе В или С получает инструкцию commit или rollback, она обязана выполнить пол)ченную команду. Если СУБД ответила yes на сообщение get ready, полученное на этапе 3, она потеряла возможность самостоятельно решать судьбу транзакции. СУБД завершает или отменяет свою часть транзакции в зависимости от полученной команды, записывает сообщение commit или rollback в свой журнал транзакций и возвращает сообщение ок в систему А.

6. Когда система А получит все сообщения ок, она будет знать, что транзакция либо завершена, либо отменена, и возвратит в программу соответствующее значение переменной sqlcode.

Система В

UPDATE COMMIT г

UPDATE

COMMIT

Система A

Система С

INSERT UPDATE

- COMMIT -►(завершена)

INSERT

UPDATE

COMMIT Увы!

INSERT

COMMIT

INSERT

ROLLBACK

Ошибка транзакция завершена в системе В, но отменена в системе С

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

Система В

Система А

Система С

update get ready

commit Г

update

get ready С

rollback

get ready

commit

get ready

rollback

insert

update

- commit -

-►(завершена)

insert

update

- commit ) Увы1 Q -> (отменена) ,

get ready

Commit

get ready

rollback

insert

get ready

commit

insert

rollback

Рис 22 14 SAeron двухфазного завершения

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

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

Предположим, что в системе С происходит ошибка после отправки сообщения YES на этапе 3 Система А решит, завершать или отменять транзакцию, в зависимости от ответа системы В Программа восстановления в системе С найдет в локальном журнале транзакций сообщение YES, но не найдет сообщение COMMIT или ROLLBACK, обозначающее конец транзакции Программа восстановления спросит у координатора (системы А), как закончилась транзакция, и выполнит соответствующие действия Обратите внимание система А должна сохранять запись о своем решении завершить или отменить транзакцию до тех пор, пока не получит окончательное подтверждение ок от всех участников, это необходимо для того, чтобы в случае ошибки она могла передать эту информацию в программу восстановления.