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

Я с пониманием отношусь к желанию предоставить пользователю красивое сообщение о том, кто держит блокировку. Но 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.

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

Запрос _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 должен работать быстрее.