Результаты поиска

Имхо - SSO ключ ставится именно на домен и оно вообще не должно работать если FQDN хоста не <host>.<domain> В данном случае тестовый сервер должен адресоваться как test.local например и SSO должно выдаваться на .local. Короткое имя - пережиток NetBios )))

Да

Ну если пароли в MD5 \etc храниятся, пофиг где хранить. А вот при SSO можно генерить штатный LtpaToken и даже если юзера нет нигде в ак, он будет виден доминой и можно использовать. Имя юзера без разницы.

Вот верно :) и бегать постояноо не надо на сервер - хранить в localStorage в ключе типа user+role+трампампам я использую JStorage - GitHub - andris9/jStorage: jStorage is a simple key/value database to store data on browser side

150 к менюха??? Может в json на бэк отдавать - а там отрисовывать уж.. И да - лучше хранить все в профильных докахб которые вычисляются 1 раз... Еще вариант - динамический запрос и сохранение в localStorage браузера. Я так храню много чего с сервера. списки для select и т.д.

Да исходящие от сервера норм и работает. Но не хочется хранить данные, их реплицировать и т п.

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

А можно пример ? Например выдача через агента ?Wsdl

Попадания в зазор на практике оказалась весьма частым явлением :) Если смотреть теоретически -Для определения “зазора“ можно глянуть статистику класт репликатора. Там более все наглядно... Со всем остальным конечно же согласен.

Если БП позволяет тратить время на тикеты то можно и не рефрешить лок. Но в моей практике такой роскоши еще не было :))

Штатный домино кластер на раз даст создать 2 дока на серверах разными пользователя с одни унидом. Там нет блокировок как в субд в ружиме мультимастер. Не нужно иметь всегда 2 активных сервера блокировок - достаточно доступа на 1, второй - в горячем резерве. Через http + nginx перекл на горячий...

А если клиент рухнет - как скоро для других блокировка считается протухшей ?

в нативном клиенте проблематично сделать надежный таймер вызова агента для обновления статуса блокировки. если только на JS. Кстати - должен в форме лотус клиета работать и JS трюк с картинкой - <img src="http://server/agent&param"/>

можно уточнить - формат бд ДАОС или формат NLO файлов ?? а то пишет щас - DAOS container manager v2.0 (daos.cf2) ....

те же яйца вид сбоку... т е - один фиг нужно точку отказа резервировать...

Отработана реализация блокировок по http для http приложений. там цимус в том что при умирании\закрытия почти гарантированно отрабатывает метод браузера navigator.sendBeacon... это можно сделать на и на delete\terminate класса\агента. + есть таймер на обновление блокировки раз в 15-30 сек...

Эт какой же титанический труд в лн клиенте... капец.

Приклад - чисто http?

Вышла 12 версия...;)

Updall -R срабатывает за неск секунд тогда, когда уже идет индексация в потоке клиента например... Именно так. Это здорово, когда все уже вычислено для индексера - для прод случай идеальный :) Но сильно не эффективно для разработки - когда нужно добавить еще ключ - перетряхивать придется...