написал небольшу заметку:
Распределенная работа над документом

Может кому поможет избежать граблей при реализации ИС с несколькими БД


^{-------
http://proactive-soft.ru}

ИзопропилДочитал до этого
авторГлубоко вдаваться в высокие понятия проектирования не будем
и стало скучно.
:) чтож популярным писателем мне не стать. жалко

gybsonне понятно о каких граблях речь

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

как и написано, решение вполне очевидное, но приходилось видеть, что в реальных системах этим конфликтом принебрегают.

mcureenabМного лишних слов.

Локальная работа - частный случай жизненного цикла документа и в плане распределённой работы ничего не даёт.
Нет документа - это не состояние документа, которого нет, а начальное и финальное состояние в терминах UML. К стати, в общем случе документ может быть уничтожен на любом этапе ЖЦ.

Распределенная работа - ближе к телу, но эти состояния ортогональны локальным состояниям, хотя и могут иметь ограничительные связи с локальными состояниями.

Алгоритм отзыва впринципе интересен, но не является единственным. На практике проще указывать не состояние документа, а владельца документа (владелец, это БД). Чтобы не возник конфликт, нового владелеца нужно изменить в рамках распределённой транзакции в локальной БД и в БД, которая по локальным данным является владельцем. Во многих СУБД распределённые транзакции реализованы в ядре.

Согласен с общими замечаниями.
Про вариант смены владельца в распределенной транзакции: такой вариант может иметь место, когда БД связаны жестко (например, через linked server для MS SQL, или клиент открывает транзакцию на двух БД).
Здесь же предлагается вариант в случае же более слабой связи (стандартная репликация СУБД, свой вариант обмена данными), БД могут работать относительно независимо.