Распределенная ИБ. Суть такая: в периферии создается документ. далее Центр должен получить этот документ для внесения корректировок и затем обратно документ должен появиться в периферии. Как обойтись без плана обмена в реализации этого взаимодействия (т.к. он вызывает блокировку в момент обмена), чтобы максимально автоматизировано обмениваться доками?

вызывает блокировку не сам план а регистрация изменений

Насчет блокировки не понял. Можно попробовать стандартную XML выгрузку загрузку.

Блокируются действия при регистрации изменений. Выгрузку загрузку через стандартную обработку рассматривал, однако хочется более автоматизировано. Чтобы после создания документа в периферии он сразу был доступен в центре и наобоорот

(3) работать в одной базе

(4) к сожалению, это не вариант

(0) Не использовать РИБ. Написать свой план обмена, используя XML сериализацию через фабрику XDTO. Гонять только нужных для этого документа данные. Тогда блокировки будут минимальны. Обмен по нему каждые 15-20 минут.

(6) Ну, да, конечно. Свой план-обмена с джек-потом и с шлю... упс - рюшками и бантиками :) И всё только ради одного документа?

(5) Вариант: подписка и Com-соединение.

Блокировки? Да они есть, а куда без них? Что-то своё писать? А вы уверены что это будет лучше? Блокировки данных при записи всё равно не удастся избежать. Да и проблему записи изменений, когда документ открыт пользователем - тоже придётся, так или иначе, предусмотреть решение.

PS: а вообще-то, у Вас какой-то неправильный взгляд на план-обмена :)) Он ничего лишнего не блокирует :)

(7) везет вам, а мне пришлось как раз отказаться от него в типовой БП из-за блокировок

Представь себе 10 бухов перепроводят базу, каждая по своей организации. Тут слава богу типовая уже более менее научилась работать параллельно.

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

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

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

(11) бред

(12) не бред. на момент выгрузки создается транзакция и ВСЕ выгружаемые объекты и таблица изменений блокируются пока вся выгрузка не пройдет. Но это - если по умолчанию параметр количества объектов в транзакции ставить.

еще раз 10 бухов уже пишут во одну табличку, там и без обменов постоянно выскакивает эта табличка

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

(13) пробовал? или одна бабка сказала?

(15) ну, у меня 60 узлов РИБ, обмены непрерывные, блокировок НЕТ

(12) Неа... не бред. Уменьшил количество объектов в транзакции до 50 и блокировки пропали (стали не заметны).
Притом, что в базе работает около 100 пользователей и они расчет себестоимости перепроводят раз 5 в день.

(16), (17) типовая БП?

(14) Не будет он останавливаться по ошибке. Немного медленнее идет и все.

(18) Отраслевая на базе УПП.

(19) ээээ у него точно также будет "ощибка блокировки"

(20) хз как в УПП, но в БП при проведении документа который формирует только проводки автоматом регистрируется для обмена 3 десятка пустых Регистра накопления

P.S> Есть желания у меня после перехода на 8.3 попробовать посмотреть как себя БП 3.0 ведет, если всё будет хорошо буду резать базу каждый год

Ну... еще есть риск в рассогласовании данных. Допустим во время загрузки обмена сервер падает и не поднимается.
После подъема, придется в обязательном порядке загрузку провести. Иначе будет много битых ссылок.

(21).1 не будет
(21).2 ну и что?

(21) Да, есть случаи, когда загрузка прерывается из-за конфликта блокировок. Но блин, они настолько редки, что их можно не рассматривать. А если сделать что количество объектов в транзакции равно 1, то вероятность возникновения блокировок значительно снизится (ну очень нужно будет постараться что б ее вызвать).

(25) +
И в плане обмена стоит настройка, что в случае аварийного завершения, повторить попытку загрузки еще 3 раза :)
Все нормально.

(26) у нас еще допилено, чтобы если он повторно загружает сообщение с тем же номером, то пропускал те объекты, которые загружены в предыдущей попытке были (так как в транзакции 1 объект - они уже и так есть в базе)

(27) Ну, это вообще сказка.
Но я у себя такое делать не буду. :)
Стараемся по максимуму поддерживать стандартную конфигурацию.

(27)  ну это явно не типовая фича

Во первых в типовой нельзя настроить ограничения на 1 объект (я так и не понял мы про 1 объект в транзакции или про количество объектов в выгрузки). Это доступно ТОЛЬКО для онлайн обмена

Во вторых типовая тупо не грузит обмен с тем же номером (типа номер меньше или равен загруженному)

(29) в транзакции

поэтому я не спорю что в самописки у вас всё хорошо и здорово, я про типовую БП

(30) это не вяжется с (27)

или у вас онлайн обмен

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

(32) при выгрузке ничего не допилено, при загрузке - (34)