Кто нибудь реализовывал распределенные (выполняющиеся одновременно в нескольких базах) транзакции на 1с?

и с той и с другой стороны будет 1ска и веб сервисы.

Условно
Мастер: начало транзакции
<вызов веб сервиса>
Слейв: начало транзакции
Слейв: Фиксация транзакции
</вызов веб сервиса>
Мастер: отмена транзакции (дедлок или еще чего не так)

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

А иначе полноценный координатор распределенных транзакций нужен. Журнал транзакций, хранение инфы необходимой для отката...

И всё равно будут возможны ситуации с рассинхронизацией в конкретный момент времени.

чувствую, будет велосипед тот еще

Если есть "мастер" (т.е. слэйв ОБЯЗАН фиксировать зафиксированные на мастере транзакции), то проще всего вести на мастере очередь зафиксированных транзакций, еще не зафиксированных на слэйве. Тогда с некоторой частотой слэйв стучится к мастеру и отрабатывает очередь (пытается зафиксировать соответствующие транзакции у себя). Для ускорения процесса мастер может через веб-сервис дать команду слэйву на внеочередную отработку очереди. ИМХО, это наиболее простая и надежная схема.
При сбое отработки очереди она будет отработана при следующем обращении. В очереди можно хранить таймстампы, чтобы при задержках обработки очереди, превышающих допустимые - сигнализировать об возникновении исключительной ситуации (длительной рассинхронизации).

(0)
му-му

Было дело, но без сервисов, а через файлы, правда сути не меняет.
forum.forum-mista.org/topic.php?id=501458&page=2

(4)(6) действия мастера зависят от ответа слейва, вот в чем дело
(5) :Р

(7) Речь же о частном случае, скорее всего? Что будет являться результатом распределенной транзакции? Проведенные документы или что-то еще?

(7) Долбим от сервера транзакцию, если надо отмену, если ответа нет, то ошибку вываливать. Или что-то еще есть?

(8) Немного сложнее реализовывал, но пусть документы.

(8) данные мастера и от других мастеров на слейве (мастер он от того, что инициирует всю эту фигню), слейв же консолидирует данные от всех и говорит мастеру, можно ли так делать, или нет. данные меняются ВНЕЗАПНО :(

мастер - вызов метода,
слейв - действия, запись предыдущего состояния объекта в таблицу транзакций
мастер - подтвержение
слейв - удаление
либо:
мастер - отказ
слейв - откат на предыдущую версию

либо вариант с сериализацией новой версии объекта

(11)
1. КАКИЕ ИМЕННО данные? Любые?
2. Если слэйв только консолидирует и выдает разрешения, то опять-таки всё сводится к (4). К нему идут за разрешениями, он посылает или разрешает. Если посылает - вопрос исчерпан. Если разрешает - то дальше по схеме в (4), т.к. если уж он разрешил, то обязан консолидировать результат.

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

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

отгрузка в Питере со склада в МСК, например

терминал не предлагать, да.

сделать таблички с некими данными, которые реплицируются средствами SQL сервера. Ну а 1С как то должна взаимодействовать с ними, и выполнять какие либо действия. Это так, в общем.

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

(15) Слэйв у тебя - по сути координатор распределенных транзакций. Пускай их журнал ведет.
Фиксируй транзакцию на слэйве после подтверждения фиксации на мастерах. В этом случае зафиксированная транзакция на слэйве - успешно зафиксированная распределенная транзакция в целом.
А незафиксированная должна инициировать откаты на мастерах. Откат, ессно, должен подтверждаться. Вся эта инфа должна учитываться в журнале распределенных транзакций координатора (слэйва), чтобы даже после существенных сбоев координатор смог раздать нужные команды. Например, периодически анализировал журнал на предмет неподтвержденных мастерами откатов и рассылал соответствующие команды через веб-сервисы, пиная слэйвы пока не получит подтверждения откатов. Можно также предусмотреть анализ журнала координатора со стороны мастеров.
В любом случае координатор (слэйв) в каждый момент времени будет иметь исчерпывающую инфу о существующей рассинхронизации (её длительности и локализации) и будет способен принимать нужные шаги для восстановления целостности распределенной базы.

"пиная слэйвы пока не полчит подтверждения откатов" читать как "пиная мастера, пока не получит подтверждения откатов".

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

(инициатором взаимодействия по условию всегда должен быть мастер)

таким образом рассинхронизация может быть только на период между вызовами слейва с подтверждениями, но на этот период БОЛЬШЕ отгрузить не получится, таким образом задача квази решена.

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

(24) ну тут уж либо поднять 100500 веб серверов, либо вести журналы во многих местах

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

Да делали. Вопрос принципиальный - в разных БД и разных серверах или просто в разных БД на одном сервере?

(27) на разных серверах, которые друг от друга на 4000КМ в максимуме (или сколько там от СПб до Иркутска):)

(0) А в транзакции что то произвольное или просто запись в какую то табличку?