Для простоты примем, что транзакция в базе данных выполнена успешно, а значит, выдана общесистемная команда COMMIT, а не ROLLBACK. После получения запроса на выполнение команды COMMIT координатор осуществляет следующий двухфазный процесс.

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

Теперь, что бы ни случилось, менеджер ресурсов будет иметь постоянную запись о работе, выполненной им в процессе обработки данной транзакции, а значит, в случае необходимости сможет зафиксировать выполненные обновления или отменить их. Если принудительная разгрузка прошла успешно, менеджер ресурсов отвечает координатору, что все "ОК". В противном случае он посылает противоположное сообщение — "Not OK".

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

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

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

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