это кэшированные значение, в однопользовательском режиме
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
это кэшированные значение, в однопользовательском режиме
Не увидел, где передаётся имя агента (хотя и это ненадёжно, т.к. один и тот же агент м.б. запущен несколько раз), ведь по идее тогда блокирует юзер (т.е. сервер), но все агенты подписаны одним и тем же пользователем.агент успевший создать очередь и станет владельцем
не совсем понял вопрос, задача интерактивно получить блокировку (и держать её, пока юзер не отпустит) или заблокировать для выполнения кода?Не увидел, где передаётся имя агента (хотя и это ненадёжно, т.к. один и тот же агент м.б. запущен несколько раз), ведь по идее тогда блокирует юзер (т.е. сервер), но все агенты подписаны одним и тем же пользователем.
Оно точно определяет, что это из другого места была создана очередь?
Что будет, если попытаться создать очередь с одним UNID из одного агента дважды?
можно применять разный подход:И для того, и для другого сразу. Вот как штатная (Hard + Soft) работает.
Я пытаюсь понять, может ли она полностью заменить штатную.
If misOwner And mAutoClose And hMQ<>0 Then Call apiMQClose(hMQ,0)
формальный признак при открытии очереди, если её удалость создать! - тот кому удалось и есть овнерМне всё-таки непонятно, кто такой здесь Owner?
это так и есть для бэка, для фронта нужно передавать статус, т.к. он получается в агенте на сервере, если мы говорим о классикеНет времени пощупать, а так по ответам и догадкам пока не кажется это надёжным. Как я думал - при блокировке (создании очереди) должен каждый раз возвращаться какой-то уникальный идентификатор, который передавать в метод разблокировки. Это было бы надёжно, - точно знаешь, что заблокировал в одном куске кода и в нём же разблокировал. А так, что-то непонятное...
Подскажите пожалуйста, как прикрутить штатную блокировку к вновь созданному документу.
1. Пользователь создает документ
2. в какой то момент тиснет ctrl+S сохраняет документ
3. продолжает работать с этим доком
Проблема в том, что на postsave doc.lock() не работает у меня - пишет не найден документ.
То есть, чтобы залочить документ в Notes-клиенте, нужно запустить агент на сервере?это так и есть для бэка, для фронта нужно передавать статус, т.к. он получается в агенте на сервере, если мы говорим о классике
все эти "извороты" только для классики и нужны
зависит от цели , но в классике использовать очереди надо на сервере (они там должны создаваться)То есть, чтобы залочить документ в Notes-клиенте, нужно запустить агент на сервере?
необязательно - как написал выше - получение ответа по хттп, но для клиентского интерактива (в классике) это кастыльноДля блокировки каждый раз создавать временный док - такая, себе, идея...
В случае падения клиента, в отличие от штатной блокировки, заблокированные доки не разблокируются. Т.е. никакого смысла, в случае использования Notes-клиента, в такой блокировки нет.получение ответа по хттп, но для клиентского интерактива (в классике) это кастыльно
для того и описывал с таймаутом...В случае падения клиента, в отличие от штатной блокировки, заблокированные доки не разблокируются. Т.е. никакого смысла, в случае использования Notes-клиента, в такой блокировки нет.
а ктож споритСамописная HTTP-блокировка, которая дополнительно позволяет блокировать/изменять документы с разных серверов сразу, гораздо лучше
В нативной блокировке я вижу только одну проблему - объединение MasterLock-сервера с настройкой Admin-сервера (об этом писал в IdeaJam, но им похоже всё равно), а так всё отлично работает.чем дальше я смотрю на класичекий подход в нотес, тем больше убеждаюсь в его негибкости
public final class ServerBean extends ConcurrentHashMap<String, Object>
однозначно получим блокировку (если ключ unid отсут. - null), но тут опять - вызов по хттп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.
Обучение наступательной кибербезопасности в игровой форме. Начать игру!