#0
by Fragster
Кто нибудь реализовывал распределенные (выполняющиеся одновременно в нескольких базах) транзакции на 1с? и с той и с другой стороны будет 1ска и веб сервисы. Мастер: начало транзакции <вызов веб сервиса> Слейв: Фиксация транзакции </вызов веб сервиса> Мастер: отмена транзакции (дедлок или еще чего не так) задача - сделать так, чтобы слейв в случае отмены транзакции мастера тоже свою транзакцию грохнул. пока есть мысль с последующей синхронизацией со стороны мастера в виде периодической передачи на слейв инфы, что же на самом деле зафиксировалось на мастере (отдельным вызовом веб сервиса) и прибиванием на слейве того, что ему не пришло в подтверждении. в таком подходе минусы очевидны - в случае коллизий теряется "онлайновость" всей этой фигни, а это одно из главных требований.
#1
by fisher
А иначе полноценный координатор распределенных транзакций нужен. Журнал транзакций, хранение инфы необходимой для отката...
#4
by fisher
Если есть "мастер" (т.е. слэйв ОБЯЗАН фиксировать зафиксированные на мастере транзакции), то проще всего вести на мастере очередь зафиксированных транзакций, еще не зафиксированных на слэйве. Тогда с некоторой частотой слэйв стучится к мастеру и отрабатывает очередь (пытается зафиксировать соответствующие транзакции у себя). Для ускорения процесса мастер может через веб-сервис дать команду слэйву на внеочередную отработку очереди. ИМХО, это наиболее простая и надежная схема. При сбое отработки очереди она будет отработана при следующем обращении. В очереди можно хранить таймстампы, чтобы при задержках обработки очереди, превышающих допустимые - сигнализировать об возникновении исключительной ситуации (длительной рассинхронизации).
#6
by supremum
Было дело, но без сервисов, а через файлы, правда сути не меняет. forum.forum-mista.org/topic.php?id=501458&page=2
#8
by fisher
Речь же о частном случае, скорее всего? Что будет являться результатом распределенной транзакции? Проведенные документы или что-то еще?
#9
by supremum
Долбим от сервера транзакцию, если надо отмену, если ответа нет, то ошибку вываливать. Или что-то еще есть?
#11
by Fragster
данные мастера и от других мастеров на слейве (мастер он от того, что инициирует всю эту фигню), слейв же консолидирует данные от всех и говорит мастеру, можно ли так делать, или нет. данные меняются ВНЕЗАПНО :(
#12
by Bober
мастер - вызов метода, слейв - действия, запись предыдущего состояния объекта в таблицу транзакций мастер - подтвержение слейв - удаление либо: мастер - отказ слейв - откат на предыдущую версию
#14
by fisher
1. КАКИЕ ИМЕННО данные? Любые? 2. Если слэйв только консолидирует и выдает разрешения, то опять-таки всё сводится к . К нему идут за разрешениями, он посылает или разрешает. Если посылает - вопрос исчерпан. Если разрешает - то дальше по схеме в , т.к. если уж он разрешил, то обязан консолидировать результат.
#15
by Fragster
он выдает решение и хранит данные о том, что мастер сделал это действие. т.е. на слейв приходит набор записей, он его анализирует и сохраняет у себя - т.к. на его основе будут приниматься решения и для других мастеров. если набор записей "невалидный" - то не записывает и говорит об этом мастеру - тот токатывает транзакцию, если валидный, то записывает и сообщяает об этом мастеру, мастер у себя фиксирует транзакцию. проблема в том, что если мастер у себя по внешним причинам не сможет зафиксировать транзакцию (или не получит ответ от слейва), то на слейве данные будут записаны, а на мастере - нет. ну и при отваливании транзакции в 1с рвется цепочка событий, и в случае неудачи оперативно сообщить об этом слейву мы не сможем
#16
by Fragster
грубо говоря - как пример - при РИБ и неактуальных остатках в узле - контролировать остатки в узле, в котором остатки актуальные.
#19
by rs_trade
сделать таблички с некими данными, которые реплицируются средствами SQL сервера. Ну а 1С как то должна взаимодействовать с ними, и выполнять какие либо действия. Это так, в общем.
#20
by rs_trade
то есть у 1С транзакция локальная, пишешь что то в табличку, ждешь, скуль передает, на том конце обратный процесс. как то так
#21
by fisher
Слэйв у тебя - по сути координатор распределенных транзакций. Пускай их журнал ведет. Фиксируй транзакцию на слэйве после подтверждения фиксации на мастерах. В этом случае зафиксированная транзакция на слэйве - успешно зафиксированная распределенная транзакция в целом. А незафиксированная должна инициировать откаты на мастерах. Откат, ессно, должен подтверждаться. Вся эта инфа должна учитываться в журнале распределенных транзакций координатора (слэйва), чтобы даже после существенных сбоев координатор смог раздать нужные команды. Например, периодически анализировал журнал на предмет неподтвержденных мастерами откатов и рассылал соответствующие команды через веб-сервисы, пиная слэйвы пока не получит подтверждения откатов. Можно также предусмотреть анализ журнала координатора со стороны мастеров. В любом случае координатор (слэйв) в каждый момент времени будет иметь исчерпывающую инфу о существующей рассинхронизации (её длительности и локализации) и будет способен принимать нужные шаги для восстановления целостности распределенной базы.
#22
by fisher
"пиная слэйвы пока не полчит подтверждения откатов" читать как "пиная мастера, пока не получит подтверждения откатов".
#23
by Fragster
ну, мысль примерно такая и была - раз в период времени отсылать на слейв то, что было реально зафиксировано с последнего такого сеанса, слейв сравнивает с тем, что он зафиксировал и не нужные данные у себя удаляет. (например через регистрацию в плане обмена и учет номеров сообщений) (инициатором взаимодействия по условию всегда должен быть мастер) таким образом рассинхронизация может быть только на период между вызовами слейва с подтверждениями, но на этот период БОЛЬШЕ отгрузить не получится, таким образом задача квази решена.
#24
by fisher
При такой схеме нужно гарантировать, что слэйв получит и корректно обработает информацию о зафиксированных транзакциях мастеров. Этим придется заниматься мастерам. То бишь, соответствующие журналы нужно вести на каждом мастере. Это получается децентрализованная схема, без центрального координатора. Тут уже смотри, как тебе удобней. Плюсы/минусы свои у каждого из вариантов.
#26
by fisher
Не обязательно. Если речь о том, что баз много, а веб-сервис только на координаторе поднят, то откатывать транзакции могут сами мастера, получая через веб-сервис нужную информацию из журнала координатора. Зато на координаторе всегда будет актуальная инфа и в части остатков и в части состояния синхронизации.
#27
by МуМу
Да делали. Вопрос принципиальный - в разных БД и разных серверах или просто в разных БД на одном сервере?
#28
by Fragster
на разных серверах, которые друг от друга на 4000КМ в максимуме (или сколько там от СПб до Иркутска):)
Тэги:
Ответить:
Комментарии доступны только авторизированным пользователям
В этой группе 1С
- Как подключить сканер Opticon opr 2001?
- СКД (условное оформление): сравнение значений 2х реквизитов
- ПФР: Зик / ПУ 5 - Как сдать перс учет ? (несоответствие инд. сведений и РСВ)
- Работа с Web страницей из 1С
- отпуска будущих периодов 97 счет
- Как отобразить подчиненный справочник в форме элемента владельца?
- Диаграмма ганта изменение цвета интервала
- Удалить символ начала файла при записи из 1С в csv
- Что значит в ЗУП "Зачесть в норму дней (часов)"?
- Различия между данными и их представлением в журнале регистрации
- не выгружается отчет рсв-1
- Неверные параметры В ИЕРАРХИИ. Как правильно написать запрос?
- Как передать с сервера дерево значений в форму?
- 1С Розница. Печать нефискального чека
- 1С УПП зачет авансов
- Как убрать пароль на модуль обработки - пароль я знаю )))
- Работа с последовательностями в 1С 8.1
- Настройки ведения учета
- УТ 10.3 Зачем указывать заказ покупателя в документе Требование-накладная?
- Корректировка стоимости списания