Распределенная обработка данных. Найханова Л.В. - 36 стр.

        нение неуспешной транзакции несмотря на неисправности произвольного харак-
        тера. Можно предположить и обратную ситуацию, т.е. что такой протокол все-
        таки существует. Пусть минимальное количество сообщений, необходимых для
        осуществления этого протокола, равняется N. Предположим теперь, что по-
        следнее из этих N сообщений утеряно по какой-то причине. Тогда либо это сооб-
        щение не является необходимым, что противоречит исходному предположению о
        минимально необходимом количестве сообщений N, либо такой протокол не
        будет работать. Любой из этих случаев ведет к противоречию, из чего можно
        заключить, что такого протокола не существует.
     5. Протокол двухфазной фиксации может рассматриваться как основной протокол.
        Однако существует множество модификаций этого основного протокола, которые
        можно и следовало бы применить на практике. Например, в варианте под
        названием протокол предполагаемой фиксации, в котором при успешном
        выполнении транзакции число сообщений уменьшается за счет введения
        дополнительных сообщений для случая неуспешного выполнения транзакции.

     Управление параллелизмом
      Управление параллелизмом в большинстве распределенных систем, как и во многих
нераспределенных системах, основано на блокировке. Однако в распределенной системе
запросы на проверку, установку и снятие блокировок являются сообщениями (здесь
предполагается, что рассматриваемый объект находится на удаленном узле), что влечет за
собой дополнительные накладные расходы. Рассмотрим, например, транзакцию Т, которая
нуждается в обновлении объекта, имеющего реплики на n удаленных узлах. Если каждый
узел управляет блокировками для объектов, хранимых на этом узле (как это было бы при
соблюдении локальной автономии), то для простейшего способа управления
параллелизмом потребовалось бы по крайней мере 5n сообщений:
      n запросов на блокировку,
      n разрешений на блокировку,
      n сообщений об обновлении,
      n подтверждений,
      n запросов на снятие блокировки.
      Конечно, можно легко усовершенствовать этот способ, используя подтверждения,
вложенные в блок данных обратного направления. Таким образом могут комбинироваться
запрос на блокировку и сообщения об обновлении, а также разрешение на блокировку и
подтверждения. Но даже в таком случае общее время обновления может быть на
несколько порядков выше, чем в централизованной системе.
      Обычный подход к этой проблеме заключается в принятии стратегии первичной ко-
пии, которая в краткой форме была представлена выше. Для данного объекта R узел, со-
держащий первичную копию объекта R, будет управлять всеми операциями блокировки,
включающими R (помните, что первичные копии разных объектов в общем случае могут
быть расположены на различных узлах). При такой стратегии множество всех копий
объекта в целях блокировки может рассматриваться как единый объект, а общее число
сообщений будет снижено от 5n до 2n+3 (один запрос на блокировку, одно разрешение на
блокировку, n обновлений, n подтверждений и один запрос на снятие блокировки).
Однако при таком решении опять утрачивается автономность, т.е. транзакция может
оказаться неуспешной, если первичная копия недоступна (даже при использовании
транзакции только для чтения), а локальная копия доступна. Заметьте, что для блокировки
первичной копии необходимы не только операции обновления, но также и операции
извлечения. Таким образом, неприятный побочный эффект при использовании стратегии
первичной копии заключается в снижении производительности и доступности данных как
для операций извлечения, так и для операций обновления.
      Другой проблемой блокировки в распределенной системе является то, что она может

36