Обход конфликтов BG-UI

[deeeman]

видит ли сервер что документ открыт в UI?

нужно для того чтобы BG(background agents) агенты не трогали документы которые в данный момент обрабатывает какой то человек.


Выход из ситуации вижу такой:
при открытии человеком документа в UI создавать дополнительный документ с unid'ом текущего, и при обработке его BG агент видит что создан дополнительный документ значит док открыт на редактирование.

Есть еще варианты параллельный работы BG (background agents) и UI?

 

[savl]

Я уж не помню, но если включена блокировка документов, doc.Save(false,false) вернет false если док заблокирован пользователем.
А так да, систему блокировок документов делать.
И такие агенты лучше запускать когда с документами точно никто не работает

 

[deeeman]

Я уж не помню, но если включена блокировка документов, doc.Save(false,false) вернет false если док заблокирован пользователем.
А так да, систему блокировок документов делать.
И такие агенты лучше запускать когда с документами точно никто не работает

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

 

[savl]

а ввести приоритеты на обработку?
Сама работа странная, 2 разных подхода в работе с документы, вот основной конфликт, а не BG и UI.
Если уж делать через запросы, то всех, тогда можно играть с приоритетами обработки.
Если на прямую, то напрямую...
Либо вводите версионность, пусть документы сохраняются как версии.

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

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

 

[VladSh]

получается конфликты BG и UI.

Решается штатным механизмом блокировки.

А есть "супер-пользователи", которые работают напрямую с документов.
и для супер пользователей не приемлемо стоять в очереди.

Рано или поздно столкнётесь с ситуацией потери консистентности системы. Например, пользователь-1 заполняет какое-то поле, а пользователь-2 (типа "супер"-пользователь) должен вычистить поле при выполнении действия от пользователя-1. В вашем подходе сначала пустое поле "вычистится" 2-м, а затем заполнится 1-м пользователем, и кто-то будет видеть кнопки, хотя действие выполнено.
Надо уходить от всяких "супер"-пользователей, тем более что это реально. Подсказка - виртуальные изменения документа для отображения в UI; система усложняется, но оно того стоит.

 

[ToxaRat]

Решается штатным механизмом блокировки.

Не решается, остаётся потом куча заблокированных документо, нужно создавать механизм который допустим часа через 4 разблокирует все документы

 

[VladSh]

Не решается, остаётся потом куча заблокированных документо, нужно создавать механизм который допустим часа через 4 разблокирует все документы

У меня не остаётся. Но можно и агент.
А лучше бы определить, где пробой в логике. Т.е. где то место, где нет разблокировки.

 

[VladSh]

Пробоя в логике может и не быть, но док останется заблокированным hard-блокировкой при крэше Клиента.
По моему, самый лучший способ - демон на сервере, который определяет, что сессия пользователя прервалась (или восстановилась?) и будет разлочивать все его доки (наверное этим же демоном надо отслеживать какие доки были заблокированы каким пользователем).

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

 

[rinsk]

Пробоя в логике может и не быть, но док останется заблокированным hard-блокировкой при крэше Клиента.
По моему, самый лучший способ - демон на сервере, который определяет, что сессия пользователя прервалась (или восстановилась?) и будет разлочивать все его доки (наверное этим же демоном надо отслеживать какие доки были заблокированы каким пользователем).

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

Уже много лет работает такого рода самопальная блокировка, сделанная еще на 5х и в свете некоторых недостатков штатной блокировки оставленная в первозданном виде. Блокировка живет на Домино базе и проблем с производительностью нет. Для внешних систем ИМХО REST API будет самое то...