Прогресс ABL, Как определить, какой конечный пользователь блокирует запись, и показать другим конечным пользователям, которые блокируют запись? - PullRequest
Новая
       84

Прогресс ABL, Как определить, какой конечный пользователь блокирует запись, и показать другим конечным пользователям, которые блокируют запись?

0 голосов
/ 12 июня 2018

Я понимаю, что Progress ABL имеет естественную тенденцию делать это:

По умолчанию Progress отображает сообщение: используется вкл.Подождите или выберите ОТМЕНА, чтобы остановить.(2624)

Это сообщение 2624 предоставляет информацию, но обычно это не то, что нужно, потому что пользователи не имеют возможности зафиксировать изменения или продолжить работу без условия STOP.Затем они возвращаются к процедуре запуска.

Тем не менее, я хочу иметь возможность отображать, какая из них блокирует запись после того, как ______ заблокирована, а затем сделать: отображение и конкретная запись заблокирована

В статье внизу этого поста я нашел информацию об использовании VST _Lock, но в документах Progress говорится об этом дословно: «Примечание. Будьте осторожны при обращении к таблице _Lock; частый доступ может потреблять большое количество системных ресурсов и негативно влиять на производительность».«.Есть ли альтернативный подход или лучшая практика к этому?Любая помощь будет принята с благодарностью.

https://knowledgebase.progress.com/articles/Article/P182366

Ответы [ 2 ]

0 голосов
/ 12 июня 2018

Я сочувствую желанию предоставить пользователю приятное сообщение о том, кто держит блокировку.Но kbase не шутит.Это очень плохая идея использовать _LOCK таким образом.

11.4 + делает его менее плохим, но это все еще очень болезненно делать в большой производственной системе.

Появится«в порядке» в небольшой системе с размером таблицы блокировки по умолчанию (-L 8192).В большой активной системе с большой таблицей блокировок (обычные значения -L к северу от 1M) и большим количеством используемых блокировок у вас будет очень, очень разный и очень отрицательный опыт.

Лучшее решение можетчтобы посмотреть на "заблокированных пользователей": 

for each dictdb._Connect no-lock
    where _Connect-usr <> ?
      and _Connect-wait <> " -- ":  /* there are spaces around the '--' */

  display _Connect.

end.

Это будет намного быстрее и может рассказать вам все, что вам нужно знать.

Если вы собираетесь сканировать _LOCK независимо от того, кто из kbaseпредупреждение, по крайней мере, поместит некоторую логику в ваш цикл, чтобы отследить, сколько времени это займет, и выручить, если это станет слишком длинным.Примерно так может быть хорошим началом: 

etime( yes ).

for each dictdb._Lock where _Lock._Lock-usr <> ? and _Lock._Lock-recid <> ?:

  if etime > 500 then leave.

  /* whatever ... */

end.
0 голосов
/ 12 июня 2018

Полагаю, вы уже знакомы с функцией find ... exclusive-lock / share-lock no-wait no-error, так как вы не можете использовать заблокированную функцию без использования no-wait.

Запрос _lockможет быть не так плохо, как комментарий звучит.Вы будете делать это только изредка, когда пользователь сталкивается с конфликтом блокировки.Кроме того, производительность в значительной степени зависит от общего количества заблокированных в данный момент записей.

Важным является правильный запрос _lock, в зависимости от версии Progress.

Повторить мой ответна аналогичный вопрос :

  • _LOCK всегда имеет полное количество записей, заданных в -L, независимо от того, сколько блокировок существует в настоящее время.

  • В до 11.4Освобождает поля, не проиндексированные, но все используемые блокировки находятся в начале таблицы, поэтому вы можете использовать 

    FOR EACH _Lock NO-LOCK:
  IF _Lock._Lock-Usr = ? THEN LEAVE.

    (_ Lock._Lock-Name =? также хорошо).См. http://knowledgebase.progress.com/articles/Article/P161995 (По-видимому, это не так на практике для очень больших таблиц блокировок или многих блокировок. Тем не менее это, вероятно, лучшее, что вы можете сделать, поскольку сканирование всей таблицы блокировок действительно занимает некоторое время.)

  • В 11.4 и 11.5 заполненные записи больше не находятся в начале, поэтому старый код даст неправильные результаты (см. http://knowledgebase.progress.com/articles/Article/000056304,, это исправлено в 11.5.1).К счастью, сканирование таблицы блокировок теперь происходит намного быстрее, поэтому вы можете использовать 

    FOR EACH _Lock NO-LOCK WHERE _Lock-Recid <> ?:

    , упомянутый в той же статье.Технически это не реализовано с помощью индексов.(Индекс не будет работать с оператором <>.)

  • Начиная с 11.5, оба варианта должны работать, но более новый вариант с фразой where должен быть быстрее.
...