Кратко

  • В Argus guardian объединял процессы, объекты и ответственность за восстановление; атомарная action делала изменения участвующих восстанавливаемых объектов сериализуемыми и действующими целиком либо никак.
  • Commit не доказывал завершение внешнего устройства, работы человека или неуправляемого ввода-вывода. Он также не устанавливал личность и деловую цель инициатора вызова.

Commit успешен, а машина не двигается

Представим handler, который обновляет устойчивый объект управления, а затем просит оборудование вне Argus выполнить действие. Topaction принимает однозначное решение. Все участвующие guardians согласны. Новые версии stable objects записаны. Вызывающая сторона получает успех.

И всё же машина остаётся неподвижной.

Противоречия нет. Argus даёт сильную гарантию для восстанавливаемых объектов, включённых в action, и не даёт её для устройства, которое не участвовало. Слово «commit» звучит как окончательное завершение. В работе Barbara Liskov и команды Argus это было точно ограниченное свойство языка и среды исполнения.

Статья 1983 года Guardians and Actions, написанная Liskov и Robert Scheifler, соединила две абстракции. Guardian группировал ресурсы, объекты и процессы распределённой программы на узле и отвечал за восстановление. Action объединяла операции, которые должны выглядеть последовательными и либо вместе создавать новое состояние, либо возвращать предыдущее восстанавливаемое состояние. Обработка отказов перестала быть набором случайных соглашений каждого приложения.

Так появилась и граница доказательства: commit имел силу внутри множества участников. За ним требовалась другая квитанция.

Область восстановления, а не страж всего мира

Guardian напоминал модуль, живущий дольше отдельного процесса. Он хранил объекты, запускал процессы и предоставлял handlers другим guardians. После отказа узла восстанавливаемое состояние можно было реконструировать, а volatile state инициализировалось заново. Ответственность за восстановление становилась явной.

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

Граница видна в модели хранения. Stable variables служили корнями для resilient objects. До commit topaction новое состояние изменённых стабильных объектов должно было попасть в stable storage. Volatile variables при восстановлении инициализировались вновь. Ссылка из stable variable не превращала нерезильентный объект в долговечное транзакционное состояние: тип и реализация восстановления по-прежнему имели значение.

Поэтому фраза «Argus делал распределённые программы надёжными» слишком общая. Он делал восстанавливаемым определённый класс состояния при определённых предположениях об отказах. Гарантию создавало именно это определение.

Вызов handler строил дерево actions

Удалённая работа не была невидимым обходом транзакции. Вызов handler другого guardian создавал call action у инициатора и activation action у цели. Аргументы и результаты пересекали границу по значению; обратный путь участвовал в завершении subactions.

Обычный return или signal обычно подтверждал activation. abort return и abort signal отменяли её. Следовательно, исключение не было автоматическим синонимом сбоя транзакции. Если исключение должно было запретить commit внешней работы, программа обязана была перехватить его на правильной границе action.

Subaction могла abort без обязательного разрушения родителя. После её commit блокировки и предварительные версии переходили родителю. Результат оставался зависимым от родителя и, в конце концов, от topaction. «Subaction committed» не означало «навсегда и независимо от вызывающей стороны».

Topaction была корнем. При commit система координировала guardians, применяла two-phase commit, когда этого требовало распределённое решение, и записывала новые версии stable objects, изменённых action и её подтверждёнными потомками. При abort управляемое транзакцией состояние возвращалось к предыдущей версии.

Иерархия предотвращает три преувеличения: успешная activation ещё не commit topaction; подтверждённая subaction не независима; commit topaction ничего не доказывает о неучастнике.

Orphan показывал неоднозначность сети

Распределённый вызов может завершиться неоднозначно. Один узел исчезает, пока работа продолжается в другом месте. Инициатор может потерять обратный путь и не знать, остановилась ли удалённая activation. Argus называл orphan action, чей предок погиб или чей результат больше не мог вернуться по цепочке.

Механизм orphan был не просто тайм-аутом. Он должен был в итоге заставить orphan abort и, прежде всего, не позволить ему увидеть несогласованные atomic data после потери законного предка. Руководство фиксирует важный неудобный факт: результат unavailable у инициатора может сосуществовать с удалённой активностью, всё ещё выполняющейся как orphan.

Отсюда две опасные ошибки. Отсутствие ответа не доказывает, что ничего не выполнялось. Принудительный abort внутри action system не доказывает отмену неуправляемого внешнего эффекта. Гарантия зависит от общения actions через atomic data. Импульс мотору, напечатанная страница, уже переданное письмо или человеческое поручение не обращаются назад из-за исчезновения предка Argus.

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

Open nesting был сознательным исключением

Обычные subactions оставались зависимы от родителя. Argus также предлагал nested topaction, способную commit независимо и сохраниться, даже если внешняя action позже abort. Это open nesting.

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

Современные outbox, шаги saga и независимые audit writes повторяют ту же форму. Отдельно подтверждённый эффект нужно назвать, а не прятать в заявлении, будто родитель откатился без остатка.

Commit определял состояние, но не личность и намерение

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

Сериализуемость также не ограничивает цель. Два запроса могут быть одинаково допустимы для интерфейса объекта, хотя одобрен только один. Обновление «всё или ничего» способно сохранить внутренний инвариант и нарушить правило, охватывающее платёжную сеть, физический процесс или организацию. Это не дефект модели; ей нельзя задавать вопрос, на который она не обещала отвечать.

Операционные доказательства должны быть многослойными. Транзакционный журнал описывает guardians, восстанавливаемые объекты, завершение subactions, решение и stable storage. Журнал идентичности описывает исполнительный principal и, при необходимости, человека, начавшего или одобрившего работу. Внешние квитанции подтверждают другой сервис, устройство или человеческий процесс. Для более широкого инварианта нужны наблюдения во всех его областях.

У научного авторства тоже есть граница

Liskov — естественная точка входа: она руководила программой и написала зрелый обзор 1988 года. Но Argus был коллективной работой. Guardians and Actions принадлежит Barbara Liskov и Robert Scheifler и благодарит проектную группу, особенно Maurice Herlihy, Paul Johnson и William Weihl. Руководство 1987 года называет Liskov, Mark Day, Herlihy, Johnson, Gary Leavens, Scheifler и Weihl. Статья о реализации написана Liskov, Dorothy Curtis, Johnson и Scheifler.

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

Источники