62. Распределенные субд: фиксация транзакций.

Глобальная транзакция разбивается на локальные транзакции, каждая из которых выполняется — на своем узле. Обновления происходят по отдельности, но с точки зрения пользователя транзакция глобальная и все

вместе должно составить единую транзакцию.

Для фиксации глобальной транзакции необходимо согласие всех узлов, обрыв может инициировать один узел.

Важная проблема: как устраивать фиксацию транзакций?

Каждая из локальных транзакций выполняется своим локальным менеджером транзакций. Все локальные транзакции должны либо зафиксироваться, либо быть оборваны — все одинаково: вот наша задача.

Для того чтобы это обеспечить, используется специальный двухфазный протокол — «протокол

двухфазной фиксации (two phase commit)».

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

Для каждой глобальной транзакции выбирается один из узлов, который назначается на должность

координатора именно этой глобальной транзакции. Но для разных транзакций роль координатора

могут выполнять разные узлы — т.е. система не централизована. Каждый узел должен быть готов взять на себя функцию координатора.

Итак, непосредственно протокол (в случае нормальной работы):

Когда координатор считает, что транзакция готова к фиксации, то наступает 1 фаза:

1. Координатор рассылает всем участникам транзакции сообщение prepare («приготовиться к фиксации») и ждет оговоренное время ответа от всех участников. Участник, получивший такое сообщение (а может из-за сбоев в сети и не получить) может поступить 2-мя способами:

• ответить координатору «готов зафиксировать» — при этом он действительно должен быть готов зафиксировать транзакцию;

• ответить координатору «надо оборвать транзакцию».

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

и она не фиксируется.

Пусть все участники ответили: «готов зафиксировать», но они должны быть готовы и оборвать, если что-то пойдет не так.

Координатор собрал сообщения о готовности от всех участников, и наступает 2 фаза:

2. Координатор рассылает команду: «зафиксировать» (commit). Участники фиксируют транзакцию.

В случае возникновения сбоя при обработке транзакции:

• После рестарта необходимо обработать транзакции в состоянии “готова”, но не “зафиксирована”

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

• Если после отсылки сообщения «подготовиться» произошел тайм-аут, то обрываем транзакцию.

• В некоторых случаях решение невозможно

конспект, стр. 57

4-consistency, слайд 54

http://en.wikipedia.org/wiki/Two-phase_commit_protocol

63. Хранение и использование xml в базах данных.

Возникла задача интеграции БД, т.е. использование данных из нескольких независимых БД как одной. Как способ решения этой задачи в середине 1990-х годов возникла слабоструктурированная модель данных.

При использовании инородных данных необходимо учитывать ряд моментов:

• Чужие данные всегда содержат ошибки

• Структура не всегда полностью известна. Неизвестны ограничения целостности, правила, триггеры, процедуры; неизвестна обязательность присутствия данных.

• Невозможно использование объектных ID

• Самое трудное: семантическая неоднородность

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

Рассматриваемые модели делятся на два больших класса.

• Модели лёгкого веса не предусматривают наличия какой-то схемы; структура есть, но возможны неожиданности.

• В моделях тяжёлого веса схема есть, и можно говорить об отклонениях от неё. Возникает задача выделения структуры (преобразования данных из лёгкого веса в тяжёлый).

Родословная XML:

• LaTeX: логическая структура документа

• SGML(Standard General Markup Language) — язык разметки, который даёт возможность создавать самоописывающиеся файлы. В нём введена концепция DTD (Document Type Definition), которая и делает документ самоописываемым. На данный момент SGML — скорее мёртвый язык.

• Гипертекстовые системы

• HTML (ранние версии): предельно упрощенный SGML + гипертекст

• XML == SGML + гипертекст. XML — это подмножество SGML с привнесёнными деталями из HTML. Сейчас XML — единственная практически используемая реализация слабоструктурированной модели данных.

Модель данных XML: данные

• Простые типы: последовательности символов

• Элементы <weight>72.3</weight>

• Последовательности <item>...</item><item>....</item><item>...</item>

• Сложные типы: элементы, содержащие последовательности одинаковых или разных элементов

• Атрибуты: описывают свойства э лhемента

XML: элементы и атрибуты

• Каждый документ XML представляет собой дерево, вершинами которого являются элементы

• Кроме значения, элемент может быть снабжен атрибутами

• Атрибуты предназначены для задания метаинформации

• Нет четкой границы между значениями элементов и атрибутами

конспект, стр. 25-26, 61-62

7-semistructured-temporal, слайд 1

Молина, стр. 187 (192)