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

Тема в разделе "Lotus - Программирование", создана пользователем fedotxxl, 16 окт 2008.

  1. fedotxxl

    fedotxxl Well-Known Member

    Регистрация:
    9 ноя 2005
    Сообщения:
    614
    Симпатии:
    0
    Гм... интересная задачка...
    Есть две реплики на двух серверах - А и Б. На А изменяют документ. Нужно произвести какое-то действие, когда документ дотечет до сервера Б. Как ПРАВИЛЬНО проверить, дошел ли документ до Б или же нет?
    Пусть условие такое - в промежутки между репликацией документ может меняться только на одном сервере.
     
  2. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    извини, но это бредовое условие :unsure:
    "все познается в сравнении". вывод - надо что-то с чем-то сравнить.

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

    Kee_Keekkenen Well-Known Member

    Регистрация:
    5 сен 2006
    Сообщения:
    616
    Симпатии:
    4
    можно проверить была ли репликация после изменения документа, а вот дошел ли это вряд ли.. чтоб сравнивать нужно брать документы из обоих баз и их сравнивать..
     
  4. Constantin A Chervonenko

    Constantin A Chervonenko Well-Known Member

    Регистрация:
    30 май 2006
    Сообщения:
    1.288
    Симпатии:
    0
    Запись в журнал репликации пишется после успешного завершения сеанса. Т.о. если сеанс был, значит все документы дошли.

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

    fedotxxl Well-Known Member

    Регистрация:
    9 ноя 2005
    Сообщения:
    614
    Симпатии:
    0
    Есть парочка идей:
    1. Нам известно какое поле мониторить на какое значение (условно говоря). Т.е. при генерации действия я задаю @ формулу, на основании которой оно исполнится.... Вариант плох тем, что не автоматический
    2. Быть может на разнице дат изменения документов?... нужен какой-то автоматический вариант
     
  6. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    мы об одном и том же говорим? :rolleyes:
    что ты подразумеваешь под "автоматическим" вариантом?..
    ты либо шире описывай мысли, либо... не знаю...
    в данном случае краткость не сестра... ;)
     
  7. fedotxxl

    fedotxxl Well-Known Member

    Регистрация:
    9 ноя 2005
    Сообщения:
    614
    Симпатии:
    0
    У меня изменился документ на сервере А. Нужно подождать, пока обновится на сервере Б и что-то сделать.
    1. Я знаю, что у меня изменилось в документе. Тогда я пишу это в виде @ формулы,например {Status = "1"}. Когда у меня на Б у документа поле Status станет равно "1", это будет означать, что реплика дошла. Такой вариант плох тем, что мне нужно знать, что изменилось
    2. Если я не знаю, что у меня поменялось, то, по-моему... теоретически можно сравнивать даты изменения документа... как вам такой вариант?
     
  8. Kee_Keekkenen

    Kee_Keekkenen Well-Known Member

    Регистрация:
    5 сен 2006
    Сообщения:
    616
    Симпатии:
    4
    не ясна конечная цель такого отслеживания..
     
  9. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    могу предположить, что это можно использовать для уведомления пользователей об изменениях в документе... правда, довольно тяжелый способ :rolleyes:

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

    rins Гость


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

    Constantin A Chervonenko Well-Known Member

    Регистрация:
    30 май 2006
    Сообщения:
    1.288
    Симпатии:
    0
    До конца не просеку, но какой-то гнильцой по-пахивает: сервера такой пинг-понг этими отметками начнут...
    Давайте еще раз:
    Кто должен убедиться в успешности репликации? Отправитель?
    Достоверно это можно сделать только сравнением всех полей документа на обоих серверах. Собственно системный репликатор этим и занимается. Написать еще один и запускать в-догонку за системным? :blink: Лажа какая-то...

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

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    бррр... а если у нас 5 серверов? то по полю на сервер?..
     
  13. rins

    rins Гость

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


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

    Это очень не надежно - например если мы задействуем 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
    ... чегой-то там осмыслить - только эт все лажа полнейшая...
     
  14. Akupaka

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    не жалко, но зачем?..
    имхо, достаточно простого сравнения, которое я в самом начале предлагал - записывать в момент редактирования в поле имя сервера, который провел изменения, на каждом из серверов работает агент по новым и измененным докам, если агент подымает документ, в котором имя сервера в поле не совпадает с именем его сервера, то этого достаточно чтобы определить, что документ был изменен и требуется выполнить какое-то действие...
     
  15. rins

    rins Гость

    кста - для небольшого количества серверов есть еще один способ - игрища с фолдерами :blink:
    Т.е. сервер Б банально складывает новые док-ты в свою, по имени сервера папку :)


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

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

    Akupaka А че я?.. О.о

    Регистрация:
    4 окт 2007
    Сообщения:
    3.373
    Симпатии:
    2
    хо... хорошее замечание :blink: я задачу понял как "выполнить что-нить на сервере Б, когда док изменен на сервере А и был реплицирован на сервер Б"

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

    Constantin A Chervonenko Well-Known Member

    Регистрация:
    30 май 2006
    Сообщения:
    1.288
    Симпатии:
    0
    Вот-вот, именно! Все будут генерить отметки про всех контрагентов и провоцировать новую репликацию на все остальные сервера. УжОссс...


    Вот-вот. READERS-поля влияют на надежность репликации. Замечательно, очень свежо

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

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

    rins Гость

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

    Constantin A Chervonenko Well-Known Member

    Регистрация:
    30 май 2006
    Сообщения:
    1.288
    Симпатии:
    0
    Нельзя. "Дьявол скрывается в деталях"(с)
    Вот-вот. Репликация - не транспортный механизм, а весьма прикладная система (хотя и часть платформы). Транспорт - это NRPC и, м.б. почта. Лепить на репликации свои средства доставки можно, но шаблонно применять к ним "традиционные" дата-граммные подходы/приемы, не учитывая специфику внутренних механизмов репликации (контроля целостности в т.ч.) - по меньшей мере неграмотно
     
  20. Kee_Keekkenen

    Kee_Keekkenen Well-Known Member

    Регистрация:
    5 сен 2006
    Сообщения:
    616
    Симпатии:
    4
    может статься что время репликации всегда позже, чем время сохранения документа, и тогда придется хранить информацию о предпоследней репликации..
     
Загрузка...

Поделиться этой страницей