3. Если узел Y является участником транзакции, выполняемой по протоколу двухфазной фиксации и координируемой узлом X, узел Y должен делать то, что предписывает ему узел X (фиксацию результатов транзакции или ее откат в зависимости от того, что именно потребуется), а это означает потерю (хотя и относительно незначительную) локальной независимости.

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

Принудительный вывод в файл - Координатор журнала строки о принятом решении - конец фазы 1 и начало фазы 2

tl t4 Is t6 t9

p 11

Участник

t3 t7

. В состоянии I ожидания

Рис. 20.5. Двухфазная фиксация транзакции

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

Каждому участнику координатор отдает распоряжение приготовиться к фиксации или откату транзакции. На рис. 20.5 показано сообщение приготовиться , отосланное в момент t J и полученное участником в момент Ь2. Далее участник принудительно помещает запись в журнал локального агента из своего физического журнала, а затем выдает координатору подтверждение ОК . Конечно, если возникнет какая-либо ошибка (в частности, если произойдет сбой локального агента), будет отослано сообщение Not ОК . На рисунке это сообщение, которое для простоты обозначено как ОК , переслано в момент t3 и получено координатором в момент t4. Как уже отмечалось выше, участник теперь теряет независимость: он должен делать то, что ему будет предписывать координатор. Кроме того, любые ресурсы, которые заблокированы локальным агентом, должны оставаться заблокированными до тех пор, пока участник, получивший распоряжение координатора, его не выполнит.

После получения подтверждения ото всех участников координатор принимает решение либо зафиксировать транзакцию, если все ответы - ОК , либо выполнить откат транзакции в противном случае. Затем в момент tS координатор добавляет в журнал запись о своем решении. Время Ь5 служит границей между первой и второй фазами фиксации транзакции.

Будем считать, что было принято решение о фиксации транзакции. В этом случае координатор отдаст распоряжение всем участникам выполнить , т.е. запустить обработку операции фиксации для локального агента. На рис. 20.5 показано сообщение выполнить , отосланное в момент t5 и полученное участником в момент t7. Участник выполняет операцию фиксации для локального агента и отсылает подтверждение выполнено координатору. На рисунке сообщение отослано координатору в момент tS и получено в момент Ь9.

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

На практике, конечно, этот процесс, в целом, значительно сложнее, чем описано выше, поскольку необходимо еще позаботиться о возможных отказах узла или каналов связи. Предположим, например, что на узле координатора сбой произошел в некоторый момент t между отметками времени Ь5 и t6. В процессе восстановления работы узла процедура повторного пуска обнаружит в журнале сведения о том, что в момент отказа некоторая транзакция была во второй фазе двухфазного процесса фиксации, после чего процесс будет продолжен, начиная с пересылки участникам сообщений выполнить . Отметим, что в период от ЬЗ т t7 участник находится в состоянии ожидания завершения транзакции. Если координатор попал в аварийную ситуацию, как указывалось выше, в момент t, период ожидания может оказаться достаточно длительным.

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

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

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

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

И в-третьих, существуют два важных варианта основной схемы, которые называются вариантами предполагаемой фиксации и предполагаемого отката соответственно [20.15]. Они будут описаны ниже.

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

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

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

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

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

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