Как правильно проверять, среплицировался ли документ на сервер или нет

fedotxxl

Well-Known Member
09.11.2005
614
0
#1
Гм... интересная задачка...
Есть две реплики на двух серверах - А и Б. На А изменяют документ. Нужно произвести какое-то действие, когда документ дотечет до сервера Б. Как ПРАВИЛЬНО проверить, дошел ли документ до Б или же нет?
Пусть условие такое - в промежутки между репликацией документ может меняться только на одном сервере.
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
#2
извини, но это бредовое условие :unsure:
"все познается в сравнении". вывод - надо что-то с чем-то сравнить.

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

Kee_Keekkenen

Well-Known Member
05.09.2006
639
6
#3
Гм... интересная задачка...
Как ПРАВИЛЬНО проверить, дошел ли документ до Б или же нет?
можно проверить была ли репликация после изменения документа, а вот дошел ли это вряд ли.. чтоб сравнивать нужно брать документы из обоих баз и их сравнивать..
 

Constantin A Chervonenko

Well-Known Member
Lotus team
30.05.2006
1 333
4
#4
Запись в журнал репликации пишется после успешного завершения сеанса. Т.о. если сеанс был, значит все документы дошли.

PS: это все, конечно, в предположении, что репликатор работает безошибочно
 

fedotxxl

Well-Known Member
09.11.2005
614
0
#5
Есть парочка идей:
1. Нам известно какое поле мониторить на какое значение (условно говоря). Т.е. при генерации действия я задаю @ формулу, на основании которой оно исполнится.... Вариант плох тем, что не автоматический
2. Быть может на разнице дат изменения документов?... нужен какой-то автоматический вариант
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
#6
мы об одном и том же говорим? :rolleyes:
что ты подразумеваешь под "автоматическим" вариантом?..
ты либо шире описывай мысли, либо... не знаю...
в данном случае краткость не сестра... ;)
 

fedotxxl

Well-Known Member
09.11.2005
614
0
#7
У меня изменился документ на сервере А. Нужно подождать, пока обновится на сервере Б и что-то сделать.
1. Я знаю, что у меня изменилось в документе. Тогда я пишу это в виде @ формулы,например {Status = "1"}. Когда у меня на Б у документа поле Status станет равно "1", это будет означать, что реплика дошла. Такой вариант плох тем, что мне нужно знать, что изменилось
2. Если я не знаю, что у меня поменялось, то, по-моему... теоретически можно сравнивать даты изменения документа... как вам такой вариант?
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
#9
не ясна конечная цель такого отслеживания..
могу предположить, что это можно использовать для уведомления пользователей об изменениях в документе... правда, довольно тяжелый способ :rolleyes:

fedotxxl, ты уже знаком с агентами? посмотри справку по агентам, trigger On event, After documents are created or modified
именно с помощью такого агента я предлагал тебе (первый ответ) реализовать проверку.
кроме того, что ты так пытаешься привязаться к собакам? скрипт не знаешь? изучай тогда, он будет подинамичнее для подобной задачи...
 
R

rins

Гость
#10
Гм... интересная задачка...
Есть две реплики на двух серверах - А и Б. На А изменяют документ. Нужно произвести какое-то действие, когда документ дотечет до сервера Б. Как ПРАВИЛЬНО проверить, дошел ли документ до Б или же нет?
Пусть условие такое - в промежутки между репликацией документ может меняться только на одном сервере.

имхо - завести поле Field_B и если на сервере B Field_B<>LastModified то это для ЭТОГО сервера новый\измененный док. Провести обработку и записать в Field_B LastModified.
Вместо LastModified можно заюзать иные признаки факта изменения док-та.
Кста - факт Field_B=LastModified означает для сервера А, что док-ты точно дошли до сервера В и там обработались.
 

Constantin A Chervonenko

Well-Known Member
Lotus team
30.05.2006
1 333
4
#11
имхо - завести поле Field_B и если на сервере B Field_B<>LastModified то это для ЭТОГО сервера новый\измененный док. Провести обработку и записать в Field_B LastModified.
Вместо LastModified можно заюзать иные признаки факта изменения док-та.
До конца не просеку, но какой-то гнильцой по-пахивает: сервера такой пинг-понг этими отметками начнут...
Давайте еще раз:
Кто должен убедиться в успешности репликации? Отправитель?
Достоверно это можно сделать только сравнением всех полей документа на обоих серверах. Собственно системный репликатор этим и занимается. Написать еще один и запускать в-догонку за системным? :blink: Лажа какая-то...

Не 100%-ная, но гораздо более простая проверка:
Сравнить время модификации док-та с записью в журнале репликации: если репликация с сервером NNN успешно завершилась после LastModified документа, значит этот док-т уже на сервере NNN
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
#12
бррр... а если у нас 5 серверов? то по полю на сервер?..
 
R

rins

Гость
#13
бррр... а если у нас 5 серверов? то по полю на сервер?..
да хоть 555. жалко что ли? :blink: Тем более там вьюха будет одна на все сервера с формулой отбора по ...бла-бла ...@Enviroment("ServerName")...


До конца не просеку, но какой-то гнильцой по-пахивает: сервера такой пинг-понг этими отметками начнут...
Это не пинг-понг - это неизбежные издержки offline систем. Обмен чеками о принятии док-та - единственно надежный способ контроля доставки до получателя.

Не 100%-ная, но гораздо более простая проверка:
Сравнить время модификации док-та с записью в журнале репликации: если репликация с сервером NNN успешно завершилась после LastModified документа, значит этот док-т уже на сервере NNN
Это очень не надежно - например если мы задействуем readers поля, то все-приплыли.
Не говоря уж о парсинге ошибок репликации из-за АСЛ например.
Можно конечно сбацать свой репликатор и через API и юзая структуру
Type REPLFILESTATS
TotalFiles As Long
FilesCompleted As Long
NotesAdded As Long
NotesDeleted As Long
NotesUpdated As Long
Successful As Long
Failed As Long
NumberErrors As Long
End Type
... чегой-то там осмыслить - только эт все лажа полнейшая...
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
#14
не жалко, но зачем?..
имхо, достаточно простого сравнения, которое я в самом начале предлагал - записывать в момент редактирования в поле имя сервера, который провел изменения, на каждом из серверов работает агент по новым и измененным докам, если агент подымает документ, в котором имя сервера в поле не совпадает с именем его сервера, то этого достаточно чтобы определить, что документ был изменен и требуется выполнить какое-то действие...
 
R

rins

Гость
#15
Есть две реплики на двух серверах - А и Б. На А изменяют документ. Нужно произвести какое-то действие, когда документ дотечет до сервера Б. Как ПРАВИЛЬНО проверить, дошел ли документ до Б или же нет?
кста - для небольшого количества серверов есть еще один способ - игрища с фолдерами :blink:
Т.е. сервер Б банально складывает новые док-ты в свою, по имени сервера папку :)


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

Короче - надо конкретику. Есть конечно подозрение, что все сводится к задаче :"...ссылка на документ по почте, когда документ еще не среплицировался на локальный сервер..."
 

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
#16
Вот только я никак не пойму... как в таком случае сервер А узнает, что документ добрался до сервера Б ??? Неужели по признаку, что поле с содержимым сервер_А поменялось на сервер_Б ? а если еще один сервер добавить?
хо... хорошее замечание :blink: я задачу понял как "выполнить что-нить на сервере Б, когда док изменен на сервере А и был реплицирован на сервер Б"

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

Constantin A Chervonenko

Well-Known Member
Lotus team
30.05.2006
1 333
4
#17
бррр... а если у нас 5 серверов? то по полю на сервер?..
Вот-вот, именно! Все будут генерить отметки про всех контрагентов и провоцировать новую репликацию на все остальные сервера. УжОссс...


Это очень не надежно - например если мы задействуем readers поля, то все-приплыли.
...
Обмен чеками о принятии док-та - единственно надежный способ контроля доставки до получателя.
Вот-вот. READERS-поля влияют на надежность репликации. Замечательно, очень свежо

И: репликация - не отсылка датаграмм, а ДВУХСТОРОННИЙ процесс. Журнал коммитится только при успешной синхронизации

Дырка в "моей" схеме конечно есть, но Вы её не видите
 
R

rins

Гость
#18
Вот-вот, именно! Все будут генерить отметки про всех контрагентов и провоцировать новую репликацию на все остальные сервера. УжОссс...
Про неизбежность накладных расходов я уже говорил. Их можно уменьшить - но эт уже детали.
Вот-вот. READERS-поля влияют на надежность репликации. Замечательно, очень свежо
И: репликация - не отсылка датаграмм, а ДВУХСТОРОННИЙ процесс. Журнал коммитится только при успешной синхронизации
Все же еще раз озвучу свое ИМХО, не отвлекаясь на мелочи - НЕ опиратся на ТРАНСПОРТНЫЕ механизмы подтверждения передачи данных, а использовать как окончательный вердик только подтверждение ПРИКЛАДНОЙ системы, как конечную цель.
Дырка в "моей" схеме конечно есть, но Вы её не видите
Ест-сно. я много чего не вижу и многое не знаю:( "На всякого мудреца - довольно простоты" :blink:
 

Constantin A Chervonenko

Well-Known Member
Lotus team
30.05.2006
1 333
4
#19
Про неизбежность накладных расходов я уже говорил. Их можно уменьшить - но эт уже детали.
Нельзя. "Дьявол скрывается в деталях"(с)
Все же еще раз озвучу свое ИМХО, не отвлекаясь на мелочи - НЕ опиратЬся на ТРАНСПОРТНЫЕ механизмы подтверждения передачи данных, а использовать как окончательный вердикТ только подтверждение ПРИКЛАДНОЙ системы, как конечную цель.
Вот-вот. Репликация - не транспортный механизм, а весьма прикладная система (хотя и часть платформы). Транспорт - это NRPC и, м.б. почта. Лепить на репликации свои средства доставки можно, но шаблонно применять к ним "традиционные" дата-граммные подходы/приемы, не учитывая специфику внутренних механизмов репликации (контроля целостности в т.ч.) - по меньшей мере неграмотно
 

Kee_Keekkenen

Well-Known Member
05.09.2006
639
6
#20
Сравнить время модификации док-та с записью в журнале репликации: если репликация с сервером NNN успешно завершилась после LastModified документа, значит этот док-т уже на сервере NNN
может статься что время репликации всегда позже, чем время сохранения документа, и тогда придется хранить информацию о предпоследней репликации..