Надежность и время понятия разные

Посмотреть вложение 28237

это кэшированные значение, в однопользовательском режиме

 

Когда кэшировано, тогда вообще нули.

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

 

агент успевший создать очередь и станет владельцем

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

 

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

не совсем понял вопрос, задача интерактивно получить блокировку (и держать её, пока юзер не отпустит) или заблокировать для выполнения кода?

 

И для того, и для другого сразу. Вот как штатная (Hard + Soft) работает.
Я пытаюсь понять, может ли она полностью заменить штатную.

 

И для того, и для другого сразу. Вот как штатная (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 читаем очередь, если облом - продолбали таймаут

 

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

 

Мне всё-таки непонятно, кто такой здесь Owner?

формальный признак при открытии очереди, если её удалость создать! - тот кому удалось и есть овнер
в случае с интерактивом - тот статус кот. будет получен из агента (или проверен в QO). В бэке - все автоматом, объект! сам будет "знать"

 

еще момент - если интерактив, придется как-то получать результат выполнения агента на сервере:
- через временный док - мне не нра
- через хттп запрос - по вкусу: rest (я предпочел бы) или форму на домине

 

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

 

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

это так и есть для бэка, для фронта нужно передавать статус, т.к. он получается в агенте на сервере, если мы говорим о классике
все эти "извороты" только для классики и нужны

 

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

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

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

 

это так и есть для бэка, для фронта нужно передавать статус, т.к. он получается в агенте на сервере, если мы говорим о классике
все эти "извороты" только для классики и нужны

То есть, чтобы залочить документ в Notes-клиенте, нужно запустить агент на сервере?

 

То есть, чтобы залочить документ в Notes-клиенте, нужно запустить агент на сервере?

зависит от цели , но в классике использовать очереди надо на сервере (они там должны создаваться)
Блокировка документов может преследовать разные цели, с моей т.з. достаточно лочить на время сохранения (т.е. внесение изменений на диск) дабы избежать конфликтов и производить это в бэке (т.е. весь код в агенте на сервере)

 

Для блокировки каждый раз создавать временный док - такая, себе, идея...

 

Для блокировки каждый раз создавать временный док - такая, себе, идея...

необязательно - как написал выше - получение ответа по хттп, но для клиентского интерактива (в классике) это кастыльно

 

получение ответа по хттп, но для клиентского интерактива (в классике) это кастыльно

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

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

 

В случае падения клиента, в отличие от штатной блокировки, заблокированные доки не разблокируются. Т.е. никакого смысла, в случае использования Notes-клиента, в такой блокировки нет.

для того и описывал с таймаутом...

Самописная HTTP-блокировка, которая дополнительно позволяет блокировать/изменять документы с разных серверов сразу, гораздо лучше

а ктож спорит
очереди "эффективны" для агентской синхронизации, для интерактива придется "городить"
чем дальше я смотрю на класичекий подход в нотес, тем больше убеждаюсь в его негибкости

 

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

В нативной блокировке я вижу только одну проблему - объединение MasterLock-сервера с настройкой Admin-сервера (об этом писал в IdeaJam, но им похоже всё равно), а так всё отлично работает.

 

вот еще подумал о блокировке через ODA, там есть serverScope, который

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), но тут опять - вызов по хттп
еще есть всякие триггеры на манипуляции с БД, там посложнее будет - калбэки писать