Блокировка документов

Gandliar

Lotus Team
16.02.2004
564
26
BIT
110
Когда кэшировано, тогда вообще нули.

Потестирую в следующем месяце на большом количестве пользователей, расскажу
 

VladSh

начинающий
Lotus Team
11.12.2009
1 797
158
BIT
232
агент успевший создать очередь и станет владельцем
Не увидел, где передаётся имя агента (хотя и это ненадёжно, т.к. один и тот же агент м.б. запущен несколько раз), ведь по идее тогда блокирует юзер (т.е. сервер), но все агенты подписаны одним и тем же пользователем.
Оно точно определяет, что это из другого места была создана очередь?
Что будет, если попытаться создать очередь с одним UNID из одного агента дважды?
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
466
Не увидел, где передаётся имя агента (хотя и это ненадёжно, т.к. один и тот же агент м.б. запущен несколько раз), ведь по идее тогда блокирует юзер (т.е. сервер), но все агенты подписаны одним и тем же пользователем.
Оно точно определяет, что это из другого места была создана очередь?
Что будет, если попытаться создать очередь с одним UNID из одного агента дважды?
не совсем понял вопрос, задача интерактивно получить блокировку (и держать её, пока юзер не отпустит) или заблокировать для выполнения кода?
 

VladSh

начинающий
Lotus Team
11.12.2009
1 797
158
BIT
232
И для того, и для другого сразу. Вот как штатная (Hard + Soft) работает.
Я пытаюсь понять, может ли она полностью заменить штатную.
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
466
И для того, и для другого сразу. Вот как штатная (Hard + Soft) работает.
Я пытаюсь понять, может ли она полностью заменить штатную.
можно применять разный подход:
- автоматическое удаление при удалении оббъекта - будет работать в бэке
- ручное удаление, при интерактиве (т.е. выставлять queue.AutoClose=False, ЕМНИП она и так False) - вызываем закрытие сами (в нужный момент, например в PS формы). пример из Delete виндового
Код:
If misOwner And mAutoClose And hMQ<>0 Then Call apiMQClose(hMQ,0)
ток проверку, в этом случае делать иначе (по статусу возвращаемому агентом, при инициализации: isOwner).

Можно и вовсе - вешать агент (в бэке - без ожидания возврата) на Sleep (с автозакрытием) - получим блокировку с тайаутом ;) интерактив запишет ч-л в очередь, если не успеет - ему на QS облом выдать (попытается прочитать, будучи овнером - а там пусто или очереди нет)
т.е. вызываем агент с юнидом (пишем туда ч-л), не ждем завершения, на QO - читаем очередь (тонкий момент - надо подумать что писать/читать), если овнер - очередь существует, пишем свой юнид, на QS читаем очередь, если облом - продолбали таймаут
 
Последнее редактирование:

VladSh

начинающий
Lotus Team
11.12.2009
1 797
158
BIT
232
Мне всё-таки непонятно, кто такой здесь Owner? В штатной лотусовской блокировке всё понятно: Owner - это EffectiveUserName, т.е. если в одном агенте залочил им, то другой агент, подписанный этим же юзером, тоже будет owner'ом, потому надо химичить с массивом пользователей, блокирующих документ, и анализировать это уже вручную. А здесь как?
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
466
Мне всё-таки непонятно, кто такой здесь Owner?
формальный признак при открытии очереди, если её удалость создать! - тот кому удалось и есть овнер
в случае с интерактивом - тот статус кот. будет получен из агента (или проверен в QO). В бэке - все автоматом, объект! сам будет "знать"
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
466
еще момент - если интерактив, придется как-то получать результат выполнения агента на сервере:
- через временный док - мне не нра
- через хттп запрос - по вкусу: rest (я предпочел бы) или форму на домине
 

VladSh

начинающий
Lotus Team
11.12.2009
1 797
158
BIT
232
Нет времени пощупать, а так по ответам и догадкам пока не кажется это надёжным. Как я думал - при блокировке (создании очереди) должен каждый раз возвращаться какой-то уникальный идентификатор, который передавать в метод разблокировки. Это было бы надёжно, - точно знаешь, что заблокировал в одном куске кода и в нём же разблокировал. А так, что-то непонятное...
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
466
Нет времени пощупать, а так по ответам и догадкам пока не кажется это надёжным. Как я думал - при блокировке (создании очереди) должен каждый раз возвращаться какой-то уникальный идентификатор, который передавать в метод разблокировки. Это было бы надёжно, - точно знаешь, что заблокировал в одном куске кода и в нём же разблокировал. А так, что-то непонятное...
это так и есть для бэка, для фронта нужно передавать статус, т.к. он получается в агенте на сервере, если мы говорим о классике
все эти "извороты" только для классики и нужны
 

Мыш

Lotus Team
12.02.2008
1 226
29
BIT
125
Подскажите пожалуйста, как прикрутить штатную блокировку к вновь созданному документу.
1. Пользователь создает документ
2. в какой то момент тиснет ctrl+S сохраняет документ
3. продолжает работать с этим доком

Проблема в том, что на postsave doc.lock() не работает у меня - пишет не найден документ.

А менять EditMode на false после сохранения - не вариант? Ну да, потом лишнее нажатие на кнопку "Редактировать", зато все "по-чесноку".
 

VladSh

начинающий
Lotus Team
11.12.2009
1 797
158
BIT
232
это так и есть для бэка, для фронта нужно передавать статус, т.к. он получается в агенте на сервере, если мы говорим о классике
все эти "извороты" только для классики и нужны
То есть, чтобы залочить документ в Notes-клиенте, нужно запустить агент на сервере?
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
466
То есть, чтобы залочить документ в Notes-клиенте, нужно запустить агент на сервере?
зависит от цели ;), но в классике использовать очереди надо на сервере (они там должны создаваться)
Блокировка документов может преследовать разные цели, с моей т.з. достаточно лочить на время сохранения (т.е. внесение изменений на диск) дабы избежать конфликтов и производить это в бэке (т.е. весь код в агенте на сервере)
 

VladSh

начинающий
Lotus Team
11.12.2009
1 797
158
BIT
232
Для блокировки каждый раз создавать временный док - такая, себе, идея...
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
466
Для блокировки каждый раз создавать временный док - такая, себе, идея...
необязательно - как написал выше - получение ответа по хттп, но для клиентского интерактива (в классике) это кастыльно ;)
 

VladSh

начинающий
Lotus Team
11.12.2009
1 797
158
BIT
232
получение ответа по хттп, но для клиентского интерактива (в классике) это кастыльно
В случае падения клиента, в отличие от штатной блокировки, заблокированные доки не разблокируются. Т.е. никакого смысла, в случае использования Notes-клиента, в такой блокировки нет.
Самописная HTTP-блокировка, которая дополнительно позволяет блокировать/изменять документы с разных серверов сразу, гораздо лучше. И ещё один громадный плюс - всегда знаешь, последняя версия документа у тебя на сервере (приехал ли он по репликации на твой сервер) или нет.

Добавлено: идея подробно здесь.
 
Последнее редактирование:

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
466
В случае падения клиента, в отличие от штатной блокировки, заблокированные доки не разблокируются. Т.е. никакого смысла, в случае использования Notes-клиента, в такой блокировки нет.
для того и описывал с таймаутом...
Самописная HTTP-блокировка, которая дополнительно позволяет блокировать/изменять документы с разных серверов сразу, гораздо лучше
а ктож спорит ;)
очереди "эффективны" для агентской синхронизации, для интерактива придется "городить"
чем дальше я смотрю на класичекий подход в нотес, тем больше убеждаюсь в его негибкости :)
 

VladSh

начинающий
Lotus Team
11.12.2009
1 797
158
BIT
232
чем дальше я смотрю на класичекий подход в нотес, тем больше убеждаюсь в его негибкости
В нативной блокировке я вижу только одну проблему - объединение MasterLock-сервера с настройкой Admin-сервера (об этом писал в IdeaJam, но им похоже всё равно), а так всё отлично работает.
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 985
611
BIT
466
вот еще подумал о блокировке через ODA, там есть serverScope, который
Java:
public final class ServerBean extends ConcurrentHashMap<String, Object>
и используя
putIfAbsent(K key, V value)
If the specified key is not already associated with a value (or is mapped to null) associates it with the given value and returns null, else returns the current value.
однозначно получим блокировку (если ключ unid отсут. - null), но тут опять - вызов по хттп
еще есть всякие триггеры на манипуляции с БД, там посложнее будет - калбэки писать
 
Последнее редактирование:
Мы в соцсетях:

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