<<
>>

Устранение тупиковых ситуаций при параллельной обработке запросов

Наглядным примером АС, в которой над БД требуется параллельно выполнять целый ряд процессов обработки, являются системы продажи авиа- или железнодорожных билетов.

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

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

Если выполняется только операция чтения данных из базы и в этот период нет операций записи, то нарушения целостности данных при параллельной обработке не происходит.

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

Вернемся снова к системе продажи билетов. Например, три различных оператора, находясь в различных транспортных агентствах города, одновременно запросили один билет до Санкт-Петербурга на 1 августа в поезде № 2, в купированном вагоне. Как в таком случае говорят, будет независимо друг от друга выполнено три процесса, или три транзакции. Под транзакцией в данном случае понимается разовое выполнение некоторой программы.

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

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

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

<< | >>
Источник: Григорьев Ю.А., Ревунков Г.И.. Банки данных. 2002

Еще по теме Устранение тупиковых ситуаций при параллельной обработке запросов:

  1. ИНФОРМАЦИЯ: ОБРАБОТКА ПАРАЛЛЕЛЬНАЯ
  2. Условие четвертое. Устранение ошибочных приемов при технике доказывания на суде.
  3. 1. Ожидания и запросы аудитории
  4. 6.4.3. Параллельный опыт
  5. 8.8. ПАРАЛЛЕЛЬНЫЕ МИРЫ
  6. 6.4.3. Параллельный опыт
  7. ПАРАЛЛЕЛЬНЫЕ МИРЫ
  8. ИНФОРМАЦИЯ: ОБРАБОТКА ПОСЛЕДОВАТЕЛЬНАЯ (
  9. 2.3.3. Реакция на ситуацию интервью, а не на первоначальную ситуацию.
  10. 3. Успеха добивается тот, кто наряду с основным делом занимается параллельными делами.
  11. Обработка материалов
  12. Статистическая обработка.
  13. ТЕОРИЯ УРОВНЕЙ ОБРАБОТКИ