A.1. Детальный пример выполнения транзакции
В этом разделе подробно описывается выполнение в среде DORA транзакции Payment из тестового набора TPC-C. Напомним, что транзакция Payment обновляет остаток на счету клиента (Customer), отражает факт совершения платежа в статистике округа (District) и склада (Warehouse) и фиксирует этот факт в журнале истории (History). Граф потока транзакции для транзакции Payment показан на рис. 4.
Рис. 4. Граф потока транзакции Payment из тестового набора TPC-C.
На рис. 9 показан поток выполнения в среде DORA транзакции Payment. Все круги раскрашены, чтобы показать потоки управления, выполняющий соответствующие шаги. При выполнении этой транзакции имеется всего 12 шагов.
Рис. 9. Пример выполнения транзакции Payment из тестового набора TPC-C в среде DORA.
| Шаг1: | Выполнение транзакции начинается с потока управления, получающего запрос (например, из сети). Этот поток управления, называемый также диспетчером (dispatcher), ставит в очереди к соответствующим исполнителям действия первой фазы транзакции. | |
| Шаг 2: | Когда действие достигает начала входной очереди, оно выбирается соответствующим исполнителем. | |
| Шаг 3: | Каждый исполнитель производит поиск в своей локальной таблице блокировок, чтобы определить, может ли он обработать действие, обслуживаемое в данное время. Если имеется конфликт, то действие добавляется к списку заблокированных действий. Его выполнение возобновится, когда завершится транзакция, действие которой заблокировало данное действие. В противном случае исполнитель выполняет действие в основном без использования общесистемного управления параллелизмом. | |
| Шаг 4: | Когда действие завершается, исполнитель уменьшает на единицу счетчик RVP первой фазы (RVP1). | |
| Шаг 5: | Исполнитель, действие которого обнулило счетчик RVP1, инициирует следующую фазу, помещая соответствующее действие в очередь к исполнителю History. | |
| Шаг 6: | Исполнитель History выбирает действие из начала входной очереди. | |
| Шаг 7: | Исполнитель таблицы History производит поиск в локальной таблице блокировок. | |
| Шаг 8: | Транзакция Payment вставляет запись в таблицу History, и по причине, которую мы объясняли в п. 4.2.1, исполнитель действия нуждается во взаимодействии с централизованным менеджером блокировок. | |
| Шаг 9: | Когда действие завершается, исполнитель History обновляет последнюю RVP и вызывает фиксацию транзакции. | |
| Шаг 10: | Когда основной сервер хранения данных производит возврат из общесистемной фиксации (с выталкиванием буфера журнала и освобождением всех централизованных блокировок), исполнитель History ставит идентификаторы всех действий в очереди к их исполнителям. | |
| Шаг 11: | Исполнитель выбирает идентификатор зафиксированного действия. | |
| Шаг 12: | Исполнители удаляют соответствующие элементы из своих локальных таблиц блокировок и ищут в списке отложенных действий действие, выполнение которого теперь можно продолжить. |
Этот детальный пример выполнения транзакции, в особенности, его шаги 9-12 показывают, что операция фиксации в DORA похожа на двухфазный протокол фиксации (two-phase commit protocol, 2PC) в том смысле, что поток управления, вызывающий фиксацию (координатор в 2PC), также посылает сообщения различным исполнителям (участникам в 2PC) сообщения для освобождения локальных блокировок. Основное отличие от традиционного двухфазного протокола фиксации состоит в том, что рассылка сообщений происходит асинхронно, и что участники не вынуждаются голосовать. Поскольку все изменения журнализуются с одним и тем же идентификатором транзакции, нет потребности в дополнительных сообщениях и вставках в журнал (раздельных сообщениях и записях Prepare и Commit [A.3]). Иначе говоря, фиксация – это одиночная операция с точки зрения журнализации, хотя по-прежнему включает асинхронную посылку сообщений от координатора участникам для освобождения локальных блокировок.
Пример показывает, каким образом DORA преобразует выполнение каждой транзакции в коллективную работу нескольких потоков управления. Кроме того, он показывает, каким образом в DORA минимизируется число взаимодействий с чреватым конфликтами централизованным менеджером блокировок за счет наличия дополнительной межъядерной пропускной способности.
