Борьба с конфликтами репликации?...

[fedotxxl]

Как всегда меня интересует методы и модели... сейчас продумываю модель борьбы с конфликтами репликации.

1. Из-за чего появляются конфликты? Пользователи редактируют документ на разных серверах.
2. Решения проблемы?
2.1. Заставлять пользователей редактировать документ на одном сервере
2.1.1 Определять главного сервера для документа. В случае попытки редактирования на ином сервере предупреждать, что редактирование данного документа должно происходить на основном сервере.
2.1.2 В случае, если пользователь откажется переходить на основной сервер, дать возможность редактировать документ, но после произведенных действий получить набор измененных полей и создать документ визу.
2.1.3 Измененный документ не сохранять, а пользователя предупредить, что изменения произойдут в после репликации на основной сервер.
2.1.4 После репликации на основной сервер запускать агент, который обработает визу и произведет изменения в документе.
2.1.5 Предусмотреть конфликты сохранения - пользователь открыл документ на редактирование, агент изменил документ, пользовател сохранил документ => механизм блокировок

Итого два механизма - блокировка, изменение документа на основе виз.
Есть другие идеи? Нужно ли вообще париться по этому поводу в документооборотном движке?

 

[Medevic]

Я думаю, что бороться с ними не надо. Это же фича, а не бага.
А вот количество возможных конфликтов надо уменьшать.
1) Распределением прав. Зачем давать толпе право одновременно редактировать один документ?
2) Разбивание документа на несколько поддокументов.
3) Умное использование поля $ConflictAction.
3) Крайний случай - блокировка. На очень крайний случай.

Потом, можно придумать умный инструмент разрешения конфликтов. Например, пишем все изменения в отдельные документы. Произошел конфликт, запускаем инструмент. Он показывает какие поля были изменены и предлагает выбрать какие изменения принять. Выбираем, жмем "Ок". Изменения пишутся, конфликт удаляется. Не забываем создать новый документ со списком изменений на случай будущих конфликтов.
Это только идея. Сам не реализовывал.

 

[fedotxxl]

Для: Medevic
Документ согласуют два человека на разных серверах. Как в этом случае быть? Поля-то меняются одни и теже, так что конфликта не избежать...

Можно выбрать один из вариантов:
1. Тот, который я предложил
2. Высылать каждому свой документ для согласования
3. ....

Есть идеи правильного решения?

 

[Sandr]

2. Высылать каждому свой документ для согласования

Это лучший способ...

 

[fedotxxl]

Для: Sandr
Аргументы? С согласованием пусть... а заполнением? Нужно все-такие универсальный механизм...
Никто не знает, как этот вопрос решается в больших системах документооборота, типа CompanyMedia, БОСС-Референт и т.д...

 

[Medevic]

3. Каждый жмет кнопку. Создается дочерний документ. Агент смотрит дочерние документы и по результатам согласует главный документ. Могут также данные заноситься.

 

[Sandr]

Для: Sandr
Аргументы? С согласованием пусть... а заполнением? Нужно все-такие универсальный механизм...
Никто не знает, как этот вопрос решается в больших системах документооборота, типа CompanyMedia, БОСС-Референт и т.д...

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

 

[fedotxxl]

Для: Medevic
Прочти вариант 1
Для: Sandr
Ладно, пусть с параллельным согласованием прокатит. С заполнением?

 

[Sandr]

Если это не паралельное согласование (любое паралельное принятие решения), то нельзя допускать одновременного доступа к документу нескольким пользователям...

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

Вариант предложенный Medevic тоже без шедульного агента не обойдется...

 

[Akupaka]

Если это не паралельное согласование (любое паралельное принятие решения), то нельзя допускать одновременного доступа к документу нескольким пользователям...

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

Вариант предложенный Medevic тоже без шедульного агента не обойдется...

эк! какой умный стал

по сабжу: попробуйте почитать документы по работе IBM Lotus Workflow (кажется так), так не плохо описана философия документооборота

 

[K-Fire]

В LWF реализована примерно такая штука: если нужно паралельное действие над документом на процессе - документ размножается (делается N копий) каждый ответственный работает со своей копией, потом эти документы сливаются в 1. Как слияние производится я не знаю, мы ни разу не использовали эту штуку, т.к. ИМХО это размножение-слияние ведет только к глюкам и непонятны пользователям.

 

[Sandr]

В LWF реализована примерно такая штука: если нужно паралельное действие над документом на процессе - документ размножается (делается N копий) каждый ответственный работает со своей копией, потом эти документы сливаются в 1. Как слияние производится я не знаю, мы ни разу не использовали эту штуку, т.к. ИМХО это размножение-слияние ведет только к глюкам и непонятны пользователям.

К каким глюкам это приводит? Уточняйте... Фраза "мы ни разу не использовали эту штуку" и "размножение-слияние ведет только к глюкам и непонятны пользователям" несопоставимы...
Эту штуку используют сплошь и рядом.. жалоб пока небыло...