Т.к. ссылки больше не работают, решил расписать концепт блокировок, полностью исключающих возникновение конфликтов.
При создании каждого документа в поле "Server" вписывается имя сервера, на котором будет производиться вся фактическая работа с документом - блокировка, внесение изменений и разблокировка.
1. Распределённый вариант.
По умолчанию в поле вписывался ТЕКУЩИЙ сервер. С 2001-го по 2010-й у нас работала самописная блокировка - создание документика в специальной блокировочной базе. Причём эту базу даже не нужно было реплицировать, достаточно было разбросать эту базу по серверам - на каждом сервере в этой базе создавались блокировочные документики, по чисто созданным и изменяемым на нём документам. То есть на каждом сервере изменялся всегда свой уникальный набор документов, чем полностью исключались конфликты репликации.
2. Централизованный вариант.
В глобальных настройках СЭД была настройка "Переводить документ на административный сервер", которая после создания и отправки документа по маршруту сразу же единоразово меняла сервер на административный. В таком случае все документы фактически изменялись только на административном сервере.
За исключением пары случаев, использовался 1-й вариант, - нагрузку по обработке документов таким образом можно было "размазать" по серверам.
3. Можно было наворотить логику по подмене сервера в поле Server, в зависимости от типа документа и т.п., определяя, на каком сервере (или кластере) данная разновидность документов чаще всего обрабатывается, но мы не стали тогда этим заморачиваться...
При появлении штатной блокировки в Lotus мы постепенно переделали код на неё (Hard-lock + Soft-lock).
Выбор штатной блокировки был обусловлен её достоинствами:
- при падении Notes документ автоматически разблокируется, что позволило полностью отказаться от ручных разблокировок документов в критических ситуациях;
- сильно упростился анализ на блокировку в UI и, соответственно, уход от конфликтов сохранения;
- штатный механизм работает гораздо быстрее самописного.
Процесс исследования и перехода занял несколько лет, пока все баги не были выловлены (можно поискать по форуму - все проблемы описаны достаточно подробно).
1. Распределённый вариант.
Т.к. MasterLock-сервер завязан на административный сервер (проблема была подробно описана здесь), пришлось:
- отказаться от репликации ACL баз - перешли на статический ACL;
- установить в каждой нашей базе каждого сервера административным ТЕКУЩИЙ сервер.
Таким образом на каждом сервере мы смогли блокировать свой набор документов, также, как это было и с самописной блокировкой. Т.е. основное требование - полностью исключить конфликты, - было выполнено.
2. Централизованный вариант.
Работал без вышеуказанных проблем и ограничений, но из-за большой нагрузки на сервер обработки мы полностью перешли на распределённый вариант, несмотря на все ограничения.
В итоге, при любом варианте блокировок (самописная или штатная) при наложении на собственный "транзакционный" механизм работа СЭД была абсолютно бесконфликтна.
Случай падения одного из ЦОД'ов тогда не рассматривался, т.к. не было критических прецедентов. Но даже в такой реализации при желании можно предусмотреть обработку документов "потухшего" сервера другим сервером, т.к. решение обрабатывать документ или нет решается на уровне скрипта.
При создании каждого документа в поле "Server" вписывается имя сервера, на котором будет производиться вся фактическая работа с документом - блокировка, внесение изменений и разблокировка.
1. Распределённый вариант.
По умолчанию в поле вписывался ТЕКУЩИЙ сервер. С 2001-го по 2010-й у нас работала самописная блокировка - создание документика в специальной блокировочной базе. Причём эту базу даже не нужно было реплицировать, достаточно было разбросать эту базу по серверам - на каждом сервере в этой базе создавались блокировочные документики, по чисто созданным и изменяемым на нём документам. То есть на каждом сервере изменялся всегда свой уникальный набор документов, чем полностью исключались конфликты репликации.
2. Централизованный вариант.
В глобальных настройках СЭД была настройка "Переводить документ на административный сервер", которая после создания и отправки документа по маршруту сразу же единоразово меняла сервер на административный. В таком случае все документы фактически изменялись только на административном сервере.
За исключением пары случаев, использовался 1-й вариант, - нагрузку по обработке документов таким образом можно было "размазать" по серверам.
3. Можно было наворотить логику по подмене сервера в поле Server, в зависимости от типа документа и т.п., определяя, на каком сервере (или кластере) данная разновидность документов чаще всего обрабатывается, но мы не стали тогда этим заморачиваться...
При появлении штатной блокировки в Lotus мы постепенно переделали код на неё (Hard-lock + Soft-lock).
Выбор штатной блокировки был обусловлен её достоинствами:
- при падении Notes документ автоматически разблокируется, что позволило полностью отказаться от ручных разблокировок документов в критических ситуациях;
- сильно упростился анализ на блокировку в UI и, соответственно, уход от конфликтов сохранения;
- штатный механизм работает гораздо быстрее самописного.
Процесс исследования и перехода занял несколько лет, пока все баги не были выловлены (можно поискать по форуму - все проблемы описаны достаточно подробно).
1. Распределённый вариант.
Т.к. MasterLock-сервер завязан на административный сервер (проблема была подробно описана здесь), пришлось:
- отказаться от репликации ACL баз - перешли на статический ACL;
- установить в каждой нашей базе каждого сервера административным ТЕКУЩИЙ сервер.
Таким образом на каждом сервере мы смогли блокировать свой набор документов, также, как это было и с самописной блокировкой. Т.е. основное требование - полностью исключить конфликты, - было выполнено.
2. Централизованный вариант.
Работал без вышеуказанных проблем и ограничений, но из-за большой нагрузки на сервер обработки мы полностью перешли на распределённый вариант, несмотря на все ограничения.
В итоге, при любом варианте блокировок (самописная или штатная) при наложении на собственный "транзакционный" механизм работа СЭД была абсолютно бесконфликтна.
Случай падения одного из ЦОД'ов тогда не рассматривался, т.к. не было критических прецедентов. Но даже в такой реализации при желании можно предусмотреть обработку документов "потухшего" сервера другим сервером, т.к. решение обрабатывать документ или нет решается на уровне скрипта.