时间戳

首页 > 解决方案 > Progress ABL，如何确定锁定记录的最终用户并显示给锁定记录的其他最终用户？

database - Progress ABL，如何确定锁定记录的最终用户并显示给锁定记录的其他最终用户？

问题描述

我意识到 Progress ABL 有这样做的自然倾向：

默认情况下，Progress 显示消息：in use by on 。等待或选择取消停止。(2624)

此 2624 消息提供了信息，但通常不是所需的，因为用户没有机会提交更改或在没有 STOP 条件的情况下继续。然后它们返回到启动过程。

但是，我希望能够显示在 if ______ 锁定之后锁定记录然后执行：显示和特定记录锁定

我确实在这篇文章底部的文章中找到了有关使用 VST _Lock 的信息，但 Progress 文档逐字说明了这一点，“注意：查询 _Lock 表时要小心；频繁访问会消耗大量系统资源并对性能产生负面影响。 " 是否有替代方法或最佳实践？任何帮助将不胜感激。

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

标签： databaseopenedgeprogress-4glprogress-db

解决方案

我很同情向用户提供关于谁持有锁的好消息的愿望。但是 kbase 并不是在开玩笑。以这种方式使用 _LOCK 是一个非常糟糕的主意。

11.4+ 让它变得不那么糟糕了，但在大型生产系统上做这件事仍然是一件非常痛苦的事情。

在具有默认锁定表大小 (-L 8192) 的小型系统上，它似乎“正常”。在具有大型锁表（1M 以北的 -L 值很常见）并且使用大量锁的大型活动系统上，您将获得非常、非常不同和非常负面的体验。

更好的解决方案可能是查看“被阻止的用户”：

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.

推荐阅读