Странная работа штатного локера

F

fedotxxl

Возникла странная проблема, которую я не могу решить:
1. Мы используем штатный блокиратор
2. Если master сервер недоступен, то при исполнении обычного кода у пользователей могут возникать конфликты репликации.
3. Все конфликтные документы заблокированы пользователями (поле $PTWriters)
4. Повторить ошибку мне пока не удается, поэтому я не могу сказать какой код виноват
5. Вероятность того, что документ кто-то поменял другой мала, т.к. между моментом открытия и нажатием на кнопку (которая приводит к конфликту) проходит достаточно мало времени

Я заметил, что документ остается заблокированным пользователем, даже когда он выходит из документа. Как в этом случае контролировать разблокирование документа?
 
Я проверяю заблокирован ли документ через LockHolders property -- может и Вам поможет. Или не в ту степь?
<div class="sp-wrap"><div class="sp-head-wrap"><div class="sp-head folded clickable">"У меня тоже недавно вылезла ситуация (вроде похожая):"</div></div><div class="sp-body"><div class="sp-content">
Пользователь создает документ, при выполнении определённого действия программно создается еще некоторое количество документов-ответов, сохраняются, сохраняется и закрывается основной документ. При этом вылезла ситуация, что как основной так и подчиненные документы заблокировались создавшим его пользователем и там и остались. Правда на нескольких тысячах доков это вылезло лишь в 2-3х случаях, но как обычно у очень важного пользователя - у себя добиться такого результата не смог.
 
Ура! Удалось хотябы воспроизвести проблему. Итак:

1. Недоступен master server
2. На queryModeChange вызывается метод Call nd.UnLock

При попытке сохранить документ вылетает сообщение о конфликтном документе.
Кто что знает по поводу этой проблемы?
 
Вот, почитайте:
-
-
-
и найдёте решение.

Добавлено: ссылки на IdeaJam больше не работают :(
 
Гм... не совсем это мне подходит... прочти плс более внимательно мою проблему
 
Все проблемы с блокировкой те же, тут более внимательно не прочитаешь ))

Для того, чтобы это работало, желательно:
Чтобы Master lock server всегда был доступен. Если нет, то отлавливать ошибку и выходить из QMCh + Вообще запрещать переводить в режим редактирования, если документ нельзя редактировать либо он заблокирован любой блокировкой не текущего процесса (Soft или Hard), тогда попросту не возникнет ситуации, когда пользователь может сохранить документ.
 
Стало самому интересно, и я прокатал эту ситуацию. Сразу же дико извиняюсь - ситуация действительно из ряда вон...

Итак, что мы имеем, если описывать подробнее.

Условие: Master-lock сервером установлен не текущий сервер.


Ситуация 1: Master-lock сервер доступен.

- Hard-lock выдаёт ошибку 4000 "You cannot update or delete the document(s) since you are not listed as an allowable Author for this document" как и было указано автором link removed, что странно, хотя в доке нет полей типа Author, но доступ к базе Editor и выше... Документ при этом не блокируется. Если можно как-то обойти - подскажите, плз!!!
- Soft-lock работает нормально: создаются поля $Writers...
- Если открывать док по Ctrl+E, то Soft-lock, естессно не срабатывает, т.е. на QMCh приходится вызывать Hard-lock, т.е. разблокировать документ при закрытии в этом случае приходится также вручную, что не красиво, но не есть проблема.


Ситуация 2: Master-lock сервер НЕдоступен.

- Hard-lock выбивает ошибку 4597, которую можно отловить и подавить, выдав нормальное сообщение.
- Soft-lock выдаёт дебильное окошко

Вывод этого окошка подавить не удастся (оно появляется перед QMCh, при даблклике по документу), но можно обойти.., чтобы при нажатии на ОК не было сообщения о том, что док изменён и избежать конфликта.

Интересный факт №1: Soft-lock по нажатию OK всё-таки блокирует документ! Он сначала пытается найти Master-lock сервер, а затем блокирует на текущем.

Интересный факт №2: при Soft-lock документ блокируется не полями $Writers, а полем $PTWriters! также было указано автором
Свойство LockHolders при этом возвращает значение из этого поля.
Метод Unlock также культурно подчищает это поле.

Интересный факт №3: если включить отключенный Master-lock сервер и на нём ещё поизвращаться блокированием/разблокированием того же самого документа, а затем отреплицировать базу, то конфликтов не будет! Хоть что-то сделано хорошо...


Итого:
1. Возникновние конфликтов можно обойти.
2. Hard-lock, если Master-lock сервер не текущий, не работает. Во втором случае это нормально, а вот в первом...

Т.е. вывод прежний: если Master-lock сервер не является текущим, то строить систему на такой блокировке гиблое дело.
 
Когда-то была идея (надо для обсуждения, потому назад в будущее ;) ):


Известно, что блокировка, устанавливается в свойствах БД (опция "Allow document locking") для сервера, который находится в ACL и помечен как административный (Master Lock Server), и создаёт на этом сервере хранилище блокировок (master lock database). В реальных распределенных системах без постоянного соединения между серверами возникают проблемы: механизм блокировок работает очень медленно, иногда неправильно, при превышении лимита времени выбрасывает ошибку с кодом 4000...

Одино из рабочих решений - блокировать или изменять документы только на их родительском сервере. Для этого приходится отключать репликацию ACL (в т.ч. галку "Enforce a consistent Acess Control List across all replicas"), и устанавливать в ACL каждой базы данных на каждом сервере свой (Master Lock) сервер, это приводит к тому, что на каждом сервере, создает свой собственный репозиторий (master lock database) для блокировок - это работает быстро и красиво.
Проблема в том, что при таком решении невозможно синхронизировать ACL, - приходится делать это вручную...

Я предлагаю переместить опцию установки MasterLock-сервера блокировки из ACL в свойства базы данных, поскольку, с одной стороны, это не имеет отношения к ACL, а с другой - сняло бы ограничение, которое позволило бы повысить настраиваемость баз данных Lotus для распределенной среды.
 
Последнее редактирование:
Я предлагаю переместить опцию установки MasterLock-сервера блокировки из ACL в свойства базы данных, поскольку, с одной стороны, это не имеет отношения к ACL, а с другой - сняло бы ограничение, которое позволило бы повысить настраиваемость баз данных Lotus для распределенной среды.
А Баба Яга против!
Если и есть такая необходимость, то нужно разделить Административный сервер и Мастерлок сервер. Тогда Мастерлок сервер можно и в свойства БД, в принципе.
Хотя по мне, то весьма логично, что они объединены и находятся вместе в таблице управления доступом! Т.к. фактически эта опция относится к подсистеме доступа к документам.
Короче, я бы не поддержал предложение в таком виде.
 
Если и есть такая необходимость, то нужно разделить Административный сервер и Мастерлок сервер. Тогда Мастерлок сервер можно и в свойства БД, в принципе.
Я ж об этом и написал. Где написано, что "убрать Админ-сервер"? :)
Хотя по мне, то весьма логично, что они объединены и находятся вместе в таблице управления доступом! Т.к. фактически эта опция относится к подсистеме доступа к документам.
Блокировка не относится к "подсистеме доступа к документам". Она возможна только при наличии доступа, но не относится. Раньше блокировки не было вообще, а система доступов была.
Из-за этого "логично" приходится выбирать, что важнее, или чтобы ACL реплицировался или чтобы блокировка нормально работала, а, соответственно, и рабочий механизм предотвращения возникновения конфликтных ситуаций...
 
Я ж об этом и написал. Где написано, что "убрать Админ-сервер"?
Ну ты же написал "переместить"! А т.к. это одно и то же свойство...
Раньше блокировки не было вообще, а система доступов была
Ну дык :) Система доступа была расширена функцией монополизации доступа на редактирование. Где не так? :(
А ежели ты для одной и той же реплики разрешаешь в одно время на одном сервере одному пользователю воспользоваться блокировкой, а на другом другому, то извини - плохая архитектура :facepalm:
В том-то и задумка, что один сервер должен этим управлять для всех пользователей приложения.
 
Система доступа была расширена функцией монополизации доступа на редактирование. Где не так? :)
Система доступов - это именно система доступов (это ACL), а ограничение на редактирование, это почти что интерфейсная фишка - в специальной БД тупо указываются доки, в которых стоит флаг, и связи с ACL здесь нет абсолютно никакой.

А ежели ты для одной и той же реплики разрешаешь в одно время на одном сервере одному пользователю воспользоваться блокировкой, а на другом другому, то извини - плохая архитектура ;)
Нигде не сказано, что на всех серверах будут меняться все документы :) Задумка просто идеальна! ;) И если бы только задумка.. реализации уже 2 штуки, прекрасно работающих.
Идеальна, если бы только не объединение настроек "админ-сервера" и "мастер-лок-сервера"...(
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!