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

Создаю подписку в базах и в РС регистрирую изменения объектов.
Структура независ.непериадического РС:
Измерения:
-ссылка
-датавремяизменения
Реквизиты:
-Флаг загрузки
-комментарий неогр. строка(тут имена файлов выгрузки и загрузки)

2 Обработки выгр. и загр. через хмл.

Перед выгрузкой записываю флаг загрузки загруженных объектов по ссылка+датавремяизменения
выгружаю невыгр. объекты сортируя по датавремяизменения

Какие могут быть подв. камни в такой схеме?

(0) изменения регистрируй в плане обмена. РС выкинь за ненадобностью. Зачем изобретаь велосипед?

Будут проблемы с обработкой, не проще через TXT или что то подобное, dbf, com и тд

(1)я же написал без плана обмена.
одна и не главная эта причина:
"Из-за системных особенностей реализации планов обмена, не рекомендуется  злоупотреблять выгрузкой изменений по планам обмена. Дело в том, что при чтении изменений блокируются все таблицы изменений. Т.е при выгрузке, план обмена не дает записать новые изменений – а следовательно блокирует и сами элементы - справочники, документы и т.д."

более это не обсуждаю

(2)нет никаких проблем с хмл.
хмл рулит.
делал уже подобное.там можно и файлами (обработки, графику) обмениваться

и какой только дятел изобрёл планы обмена для обмена?..

(4) txt рулит, скорость раз в 10 больше :)

подв камни - если много пользователей одновременно начнут запсиывать объекты. РС заблокируется

(7)не заблокируется. sql
на уровне записей. в 1 сек. 1 и тот же объект записывать одновременно? не смогут.

(8) эскалация блокировок есть ещё. скуль может сам решить блокирнуть всю таблицу

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

Создавать альтернативный механизм - ИМХО, бесперспективно.

(10) согласен полностью. велосипед, причем с квадратными колёсами это будет

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

(3) тебя это не коснется

или там 100500 юзеров?

блокировка таблиц изменений отдельная тема вобще, (3) не повод совершенно

+(16) именно блокировка которая накладывается когда объекту присваивается НОМЕРСООБЩЕНИЯ и делает планобмена более "устойчивым" к передаче изменений чем РС. Так например идет выгрузка по РС а этот объект в этот момент меняют и записывают. Я давно после 7.7 делал обмен по РС (конфа самописная) пока не получил таких глюков и не перешел на планы обмена.

(3) Ну заблокируется на 2-3 секунды. Не критично.

+(17) "Выгрузка данных сопровождается созданием объекта с типом ЗаписьСообщенияОбмена (переменная ЗаписьСообщения). Сразу после создания этот объект еще «не знает» своего номера, получателя и т. п. Вся подобная информация указывается при выполнении метода НачатьЗапись(). В качестве первого параметра передается объект ЗаписьXML, в качестве второго – ссылка на узел плана обмена (ссылка на получателя). При выполнении этого метода сообщению присваивается номер, определяемый как номер предыдущего отправленного сообщения, увеличенный на 1 (информация берется их узла-получателя). Производится запись в XML-документ заголовка сообщения, а также записывается начало элемента XML, соответствующего телу сообщения. Устанавливается блокировка на запись базы данных, соответствующая узлу плана обмена."

(18) меньше, намного причем

(20) Ну, может они там только и делают, что объекты пачками меняют...

>>Вся подобная информация указывается при выполнении метода НачатьЗапись()
Вобще то при методе ВыбратьИзменения()

(22) + точней в обоих

да не суть короче.

(20)(21) я хз, у меня процесс обмена идёт иногда только выгрузка минут 30-40, загрузка часа 2-3. В этом случае блокировки таблиц изменений доставляют конечно неудобства

+(23) аха, НачатьЗапись() - сам номер сообщения а в ВыбратьИзменения() - этот номер уже проставляется в таблице регистраций

(24) А сколько объектов при этом в сообщении?

(18)частота обмена 5 мин. будет критично особо в расчетные периоды и так проблемы есть с произв-стью

(26) тысяч 400-500, из низ 300 независимый непериодический регистр великий и могучий ГрафикиРаботПоВидамВремени. Будь проклята концепция блока ЗУП и будь проклят автор регистра в частности

(27) В таком случае проблема будет не от блокировки таблицы регистрации изменения... и изобретать велосипед, как бы, незачем.

(28) Это что, 2,5 тыс. сотрудников и обмен раз в месяц?

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

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

(30) Кстати, не пробовали не передавать графики работы по видам времени, а только записи регистров расчета? Ведь, по идее, если потребуется перерассчитывать что-то, то делать это будут в филиале...

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

(33) Ну не знаю - если вводить табель учета Т-13, так он же медленно проводится с таким количеством записей в регистре...

(34) не быстро но терпимо. Я это всё к тому что и обмены бывают здоровы, и фиг чего с этим сделаешь, без перепроектирования системы или смены концепуии. А это уже делать не будут, пока совсем ен встанет колом всё

(28) сделай его подчиненным. или основной отбор убери у даты, например (ну, там потестить надо, да, но должно полегче стать)

вообще не понимаю, зачем лепить основной отбор у всех измерений

(0) >Хочу обойтись без планов обмена (без правил и КД) без флага распределенная- есть причины не хочу тут это обсуждать.
Могу попробовать расшифровать: "лень учить эти механизмы" :)

(3) >при чтении изменений блокируются все таблицы изменений.
А ты в курсе, зачем блокируются? Расскажи, как будешь решать эту проблему (согласованности) в своем механизме.

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

(37) или за счет чего думешь будет ускорение?

(39) выгружается по флагу "основной отбор"

(38)
1. ошибаешься, уже работал и нравилось
но тут др. ситуация десятки переф. баз там еще полбеды, а в ЦБ они все будут каждые 5 мин. загружать и тут уже беда- клиент порвет.
2.какой согласованности? не вижу проблем все должно паралельно грузиться, тем более загрузка будет облегченной без всяких расчетов движений

+(42) паралельно т.е. одновременно из разных баз будут грузиться объекты одного вида, а с планом обмена таблицы блокируются.

(3) вот сам и ответил на свой вопрос, без блокировки данных в момент обмена ничего путного не получится, ты просто будешь терять те изменения которые произошли в момент обмена.
доли секунды а вероятность катастрофическая.

(44)в РС ничего не будет теряеться
обект пусть хоть 100 раз меняется, он будет 100 раз регистрироваться в РС или чуть меньше, если в 1 сек паралельно несколько раз,
выгружаться то он всегда актуальный будет

(3)+ блокируются не какие-то таблицы изменений, я вообще не понял что ты имел в виду, а блокируются те объекты которые изменены. если из 10 документов 5 изменены и подлежат выгрузке то блокируются только эти 5 документов.
почему? да потому что выгрузка длится какое-то время например минуту, вот выгрузился в xml первый документ и пока выгружаются все остальные кто то взял и изменил этот первый документ. в xml осталась старая версия а в базе уже другая, и признак измененности уже не стоит.

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

(46)"в xml осталась старая версия а в базе уже другая, и признак измененности уже не стоит"
признак измененности в РС проставится и при следующей выгр. уйдет новая версия проблемы не вижу.
вот при плане обмена изменить не даст- это проблема

(48) ну ладно, а то что я в (47) написал как обходить будешь?

(42) 1. Расшифруй, что значит "клиент порвет"? Пока я понял, что проблемы на приемнике, то есть не в части записи изменений. В чем же?

2. Изменение, записываемое в таблицу изменений во время выгрузки, должно попасть либо в эту, либо в следующую выгрузку. Без блокировки могут быть ситуации, когда оно никуда не попадет.

>>Измерения:
>>-ссылка
>>-датавремяизменения

интересно а квитирование будет или рассматриваете "только гарантированная доставка" ? Интересно послушать как вы это в вашей схеме реализуете

(49)коллизию возможны, постараюсь их учесть, что то типа сразу получать объект, а не потом его из-ссылки когда он может измениться.

но блокировать же всю таблицу как с планом обмена - для моей ситуации очень плохо.

(51)получается "только гарантированная доставка" каждого объекта

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

(54)откуда инфа? я в (3) не сам придумал

у нас на подобном велосипеде работает обмен с подсотню магазинов, хочу переделать на планы обмена, но боязно ))

(40) за счет того, что наборы станут больше

(57)+ соответственно, наборов станет меньше

но тут надо тестить

(59) в первую очередь механизмы записи регистра

(53) ноу комментс :) ТС все ж рекомендую почитать про штатные возможности платформы http://langslab.com/ebooks/prof-dev2/tome2/pr-dev-t2-ch19

(55) для файловой базы (3), для скульной (54)

(55) поэксперементируй в пустой базе, сделай регистрацию одного документа, поставь точку остановки после  строки
ПланыОбмена.НачатьЗапись(); и попробуй изменить тот документ который не был изменен до  
ПланыОбмена.НачатьЗапись(); он нормально запишется.

(61)глянул тем более придется отказаться от плана обмена см.(28)ибо конфы большей частью типовые и куча регистров в которых основной отбор- нафик-нафик

(62)это я читал, это общие декларируемые отличия файловой от серверной версии еще по моему в 8.0 писали
у плана обмена заточено под свои таблицы состава объектов

(64) ты не равняйся на (28), это 2 ошибки у нас, которые не надо допускать.
1. Учет ведут неправильно (юзают табеля, это прошлый век).
2. НЕ надо этого всего добра поидее в центральной базе.

(17)(46) ну если к слову то проблема потери данных решается легко добавлением реквизита с уникальным идентификатором к записи регистра сведений. Просто перед удалением записи после выгрузки нужно проверить изменился идентификатор или нет.

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

у планов обмена есть 1 минус - нельзя сделать поэлементное подтверждение о загрузке получателем. Если какой-то 1 элемент из набора данных не может загрузиться в получатель то при каждой итерации выгрузки размер пакета будет только увеличиваться.
Да и блоками например по 100 записей выгрузку не сделаешь.

(69) сделаешь, просто нужно выгружать руками и после - перерегистрировать

(69) Можно, регистрацию изменений можно удалять поэлементно. Надо просто предусмотреть передачу информации о принятых объектах.

(70) ты про поэлементное подтверждение или по выгрузку блоками?
(71) удалять можно, но вот что в ответе от получателя использовать в качестве идентификатора элемента? UUID?

(70) я так понял про выгрузку блоками. Ну кстати тоже вариант, правда лишние записи в таблицу регистрации.

(0) у тебя кстати будет проблема с регистрацией изменений регистров сведений. "Ссылкой" тут уже не обойдешся.

(72) про выгрузку блоками

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

(76) нууу, веб-сервис то конечно в этом плане "рулит".

(77)+ правда чтобы такая схемар работала придется web сервис с обеих концов обмена поднимать. Иначе я пока не могу представить как со стороны запрашивающей базы выбирать по одной записи из плана обмена который находится на стороне базы с web-сервисом.

(78) Да. А в чем проблема?

(79) ну например, есть веб-сервис торчащий из базы в которой в плане обмена некоторое количество записей.
Метод 1: запросить через веб-сервис данные первой записи из плана обмена. Обработаем её (что-то загрузим) и вызвав другую функцию веб-сервиса скажем ему удалить данную запись из плана обмена. Нужно получить следующую но как на стороне веб-сервиса запомнить что он отдал уже предыдущую запись?
Метод 2: получить данные по всем записям плана обмена. И обрабатывая по одной вызывать функцию веб-сервиса передавая что-то в качестве идентификатора чтобы на стороне веб-сервиса удалилась запись из плана обмена.

Вобщем непонятки одни. Пока нет четкой картины. Как раз буду пробовать в ближайше время, может что придумается.

(80) все не так :)

есть вебсервис, у него один метод - ЗаписатьОбъект. Обработкой обмена вызываем его, передавая зарегистрированный объект, если он выполнился - снимаем объект с регистрации.

т.е. не запрашиваем данные, а пропихиваем

(82) либо ты меня не понял либо я тебя. Это ты описал передачу в объекта в сторону базы с веб-сервисом. А в обратную сторону?

(83) в каждом узле по севису, в который остальные узлы пихают данные

(83) (84) Народ, вы чего? Это распределенные транзакции, 1С их не умеет. Забудьте.

(85) где в моем варианте "распределенная транзакция"?

(86) "если он выполнился - снимаем объект с регистрации" - вот здесь. Без транзакции тут будет попа.

(87) ну не получилось снять с регистрации, да и пофиг, еще раз отправим...