Распределенные базы данных и протокол двухфазовой фиксации транзакций
INFORMIX-OnLine DS поддерживает запросы к распределенным базам данных и автоматически применяет протокол двухфазовой фиксации для транзакций, которые модифицируют данные более чем на одном сервере баз данных, например: CONNECT TO stores@italy BEGIN WORK UPDATE stores:manufact SET manu_code = 'SHM' WHERE manu_name = 'Shimara' INSERT INTO stores@france:manufact VALUES ('SHM', 'Shimara', 30) INSERT INTO stores@australia:manufact VALUES ('SHM', 'Shimara', 30) COMMIT WORK
Здесь BEGIN WORK, COMMIT WORK - инструкции, отмечающие начало и конец транзакции, stores - имя базы данных, italy, france, australia - имена серверов.
Внешне такая транзакция выглядит как транзакция в локальной базе. На самом деле она состоит из ряда локальных транзакций, каждая из которых может быть либо зафиксирована, либо прервана. Распределенная транзакция фиксируется только в том случае, если зафиксированы все локальные транзакции. Если хотя бы одна из локальных транзакций была прервана, то необходимо прервать и все остальные.
Каждая транзакция, реализуемая согласно протоколу двухфазовой фиксации, выполняется под управлением одного сервера, называемого координатором. В качестве координатора выбирается текущий сервер. В примере выше это будет сервер italy, поскольку к нему относится оператор CONNECT.
Первая фаза начинается с того, что координатор, получив от пользователя инструкцию COMMIT WORK, рассылает серверамучастникам сообщения о том, что нужно подготовиться к фиксации. Каждый участник решает, может ли он зафиксировать свою часть транзакции, и посылает соответствующее сообщение координатору.
Вторая фаза начинается, когда координатор, получив сообщения от участников, принимает решение о фиксации или откате транзакции. Если все участники прислали положительные ответы, то координатор посылает им сообщения о том, чтобы они зафиксировали свои локальные транзакции. Если хотя бы один участник прислал отрицательный ответ или вообще не прислал ответа, то координатор прерывает транзакцию и посылает всем участникам сообщение о том, что транзакцию нужно откатить.
Процедура восстановления
Если один из серверов вышел из строя до завершения протокола двухфазовой фиксации транзакции, то необходимо восстановить совокупную согласованность распределенных данных. Для этой цели в INFORMIX-OnLine DS предусмотрены специальные процедуры восстановления, которые автоматически выполняют все необходимые действия с учетом того, в какой ситуации и на каком сервере произошел отказ. Единственное, что должен сделать в этой ситуации администратор - это перезапустить сервер.
Оптимизация транзакций
При обработке распределенных транзакций INFORMIX-OnLine DS использует метод оптимизации, основанный на предположении о прерывании транзакции (presumed abort optimization). Смысл его заключается в том, что, если в журнале транзакций отсутствует информация о некоторой глобальной транзакции, то считается, что она прервана. Этот метод позволяет сократить число операций обмена с диском, а также число сообщений, пересылаемых между серверами.
Рассматриваемый метод оптимизации позволяет исключить два шага из классического протокола двухфазовой фиксации транзакций. Во-первых, координатор не производит синхронизированной записи на диск о начале транзакции. Синхронизированная запись на диск - дорогостоящая операция, и координатор производит ее только в двух случаях - когда все участники присылают сообщения "могу зафиксировать", и когда все участники присылают сообщения "транзакция зафиксирована". Если происходит отказ координатора до принятия решения о фиксации, и в журнале отсутствует информация о данной глобальной транзакции, то все участники считают, что она прервана, и откатывают свои части транзакции. Во-вторых, оптимизация достигается тем, что участники не должны посылать координатору подтверждения об откате транзакции. Координатор, если он принял решение об откате, рассылает участникам соответствующие сообщения, и сразу же откатывает глобальную транзакцию, изымая информацию о ней из свой разделяемой памяти.
Разрешение тупиковых ситуаций
Тупиковая ситуация возникает, например, когда работают два пользователя, и каждый блокирует объект данных, необходимый другому. Каждому из них, для того чтобы завершить обработку и разблокировать свой объект, необходимо получить доступ к объекту, заблокированному другим пользователем. Если оба объекта находятся на одном сервере, то INFORMIX-OnLine DS самостоятельно обнаруживает и предотвращает такие ситуации. При обработке распределенных запросов используется параметр конфигурации DEADLOCK_TIMEOUT - время, в течение которого INFORMIX-OnLine DS ожидает разблокирования объекта данных. По истечении этого периода одному из пользователей выдается сообщение об ошибке.
