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

fedotxxl

Well-Known Member
09.11.2005
614
0
#1
Как всегда меня интересует методы и модели... сейчас продумываю модель борьбы с конфликтами репликации.

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

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

Medevic

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

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

fedotxxl

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

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

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

Sandr

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

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

fedotxxl

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

Medevic

Что это ? :)
Lotus team
10.12.2004
3 346
2
36
Россия, Калуга
#6
3. Каждый жмет кнопку. Создается дочерний документ. Агент смотрит дочерние документы и по результатам согласует главный документ. Могут также данные заноситься.
 
S

Sandr

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

fedotxxl

Well-Known Member
09.11.2005
614
0
#8
Для: Medevic
Прочти вариант 1
Для: Sandr
Ладно, пусть с параллельным согласованием прокатит. С заполнением?
 
S

Sandr

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

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

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

Akupaka

А че я?.. О.о
04.10.2007
3 360
2
34
Kiev, Ukraine
#10
Если это не паралельное согласование (любое паралельное принятие решения), то нельзя допускать одновременного доступа к документу нескольким пользователям...

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

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

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

K-Fire

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

Sandr

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