Initial. состояние сайта := “готов”

состояние сайта:= “готов”

Endi

Event

case message = “приготовиться к изменениям”:

if test(состояние сайта) = “готов” then

Begin

write(“начинается обновление”);

блокировка доступа к копии БД;

out (“готов”);

schedule (TimeOut, T)

End

Else

Begin

write(“не готов”); out (“не готов”); откат транзакции

End

message = “общее обновление”:

if test(состояние сайта) = “готов” then

Begin

write(“произведено обновление”); put; out (“выполнено”);

End

Else

Begin

write(“не готов”); out (“не выполнено”); откат транзакции

End

message = “общий возврат”:

Begin

write(“отказ инициатора обновления”); откат транзакции; out (“отказ принят”);

состояние сайта:= “готов”

End

Endc

ende;

event TimeOut;

состояние сайта:= “не готов”; снятие блокировки доступа к копии БД

ende.

Переменная «состояние сайта» является на каждом сайте разделяемой между менеджером копии и другими управляющими программами. Первоначально менеджер копии m_j устанавливает ее значение как “готов”. Впоследствии другие управляющие программы могут присваивать ей как значение “готов”, так и значение “не готов”.

Таким образом, при получении пакета изменяемых данных и сообщения (message) “приготовиться к изменениям” от менеджера M состояния сайтов с копиями могут быть различными.

В случае готовности менеджер сайта с копией БД заносит в свой журнал запись “начинается обновление”, блокирует доступ пользователей к копии БД, сообщает менеджеру M о своей готовности и включает «часы» для ожидания в течение времени T. Если транзакция не завершается почему-либо в течение этого времени, то состояние сайта меняется на “не готов” и блокировка доступа к копии БД для пользователей снимается. В дальнейшем готовность может быть вновь установлена, но в данном протоколе это действие не отражено.

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