Репликация и проверка целостности данных

[nvyush]

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

Как я понял идею rinsk, на каждом сервере агентом After documents are created or modified к новым/изменившимся документам добавляется ответный документ-квитанция. В случае удачной репликации документы квитанции поступают на инициировавший сервер, и по их наличию/ содержанию можно определить, что изменения гарантированно доставлены. КМК, в случае активной работы с документами квитанции "откушают" приличный кусок репликации.

 

[Klido]

"откушают" приличный кусок репликации.

они откушают приличный кусок всего ^_^ но главное - их репликация также абсолютно негарантированна в контексте тему топика

 

[nvyush]

они откушают приличный кусок всего ^_^ но главное - их репликация также абсолютно негарантированна в контексте тему топика

Механизм квитирования может быть любым, хоть на веб-сервисах, смысл же простой — получили квитанцию, значит информация гарантировано доставлена, не получили квитанцию — тут уже 50/50, что именно потерялось. Что касается целостности данных, то от Лотуса не стоит требовать невозможного, он этого не умеет и для этого не предназначен.

 

[Akupaka]

Механизм квитирования может быть любым, хоть на веб-сервисах, смысл же простой — получили квитанцию, значит информация гарантировано доставлена, не получили квитанцию — тут уже 50/50, что именно потерялось

О! Правильный термин подобрал ))

 

[VladSh]

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

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

Это можно решить, если объединить решения (фух, запарился искать...):
https://codeby.net/threads/34315.html
https://codeby.net/threads/33879.html
в одно целое ^_^

Что касается целостности данных, то от Лотуса не стоит требовать невозможного, он этого не умеет и для этого не предназначен.

Похоже это и есть ответ на subj

 

[rinsk]

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

Ест-сно все квитки доставляются тем же транспортным механизмом что и основные сообщения Дело в том, что формируемый прикладной системой квитки позволяют абстрагируясь от транспортной системы однозначно идентифицировать сам факт доставки сообщения. Далее варианты - например по таймауту уже можно бить тревогу а не лазить по логам, хистори и тд...
Особенно это актуально, когда непредсказуемы маршруты промежуточных узлов доставки сообщений...
Что касается объемов... Для меня эт вопрос скорее уже философский) Помню как десятки отделений в деревнях через телеграфные адаптеры в 50-150 бод общались с Дионисом... И на каждый файл формировался квиток...




Добавлено:

Что касается целостности данных, то от Лотуса не стоит требовать невозможного, он этого не умеет и для этого не предназначен.

Именно! Мало того - в контексте топика этого никто не умеет - кроме как специально заточенного под это дело класса продуктов под общим названием Message Oriented Middleware...

 

[TIA]

Обобщение проблемы известно как

Ссылка скрыта от гостей