Кратко

  • RFC 2371 стандартизировал узкое двухфазное соглашение менеджеров транзакций, а не передачу, авторизацию или подтверждение бизнес-запросов.
  • PREPARED и COMMITTED давали сильные, но ограниченные свидетельства: они не доказывали участие всей задуманной работы и получение результата вызывающей стороной.

Два канала вместо одной всезнающей системы

В июле 1998 года RFC 2371 описал Transaction Internet Protocol, TIP, как простой протокол двухфазной фиксации. Содержание заказа, бронирования или перевода шло по протоколу приложения. По другому каналу менеджеры транзакций договаривались о фиксации или откате. В документе это называлось моделью «двух труб».

Такой разрез позволял не стандартизировать форматы данных и словарь каждого бизнеса. Существующие приложения сохраняли собственные сообщения, а менеджеры делили лишь небольшой язык координации. TIP не объявлялся заменой всех уже существовавших протоколов фиксации.

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

Границу транзакции чертило приложение

В торговом примере локальный менеджер и несколько удалённых менеджеров объединяют заказы в одну транзакцию. TIP обеспечивает атомарное решение для зарегистрированных участников. Какие действия входят в набор и когда можно начинать COMMIT, решает приложение.

RFC 2372 подчёркивал следствие: при двух раздельных каналах TIP не всегда может обеспечить порядок всех прикладных сообщений. Нельзя начинать фиксацию, пока остаются запросы в работе, и нельзя сообщать успех до регистрации у локального менеджера. Ожидаемый, но не зарегистрированный участник окажется за пределами гарантии.

Атомарность защищает объявленную границу, но не обнаруживает забытый элемент.

URL TIP был местом встречи

Контекст передавался через PUSH или PULL. В PUSH старший менеджер предписывал младшему связать транзакцию. В PULL приложение передавало URL TIP, а младшая сторона использовала адрес и ссылку для регистрации.

URL должен был оставаться глобально уникальным навсегда, однако способ генерации не задавался. UUID упоминался как один вариант; более поздний RFC 4122 нельзя считать обязательным форматом 1998 года. Сам TIP URL не исполнял — ссылку переносило приложение.

Наличие ссылки не доказывало успешный PULL, авторизацию операции или фиксацию ресурса. Это была координата встречи, а не квитанция.

PREPARED создавал долговременное обязательство

TIP обычно работал поверх TCP, мог согласовать TLS и поддерживал несколько транзакций на одном соединении. Состояния Initial, Idle, Begun, Enlisted, Prepared, Multiplexing, TLS и Error ограничивали допустимый диалог менеджеров, но не описывали всю бизнес-операцию.

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

COMMIT тоже имел узкий смысл: решение координатора для зарегистрированного множества. COMMITTED сообщал протокольный результат участника. Между ним и квитанцией клиента оставались локальная запись, доставка ответа, интерфейс приложения и последующее наблюдение состояния.

Успех мог произойти без последнего ответа

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

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

Защита не переходила между каналами автоматически

TLS допускался, но его применение задавала местная политика. RFC предупреждал: защищённое приложение можно подорвать, оставив протокол фиксации без защиты. И наоборот, защищённая сессия TIP сама по себе не доказывала личность или полномочия инициатора покупки.

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

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

Через принцип Lu Heng о минимальной начальной спецификации эта узость выглядит достоинством: стандарт охватывал ровно необходимое соглашение, не присваивая семантику приложений. Приоритет работающего кода требует искать постоянные записи, переходы и восстановление, а не верить названию. Слои реальности не позволяют считать COMMIT, COMMITTED, сообщение на экране и позднейший баланс одним фактом.

RFC 2371 давал ценную квитанцию системы координации. Он не превращал её в квитанцию всей бизнес-операции.