12

我有一个类似于票务工作系统的 Web 应用程序。一些用户输入新问题。其他工人选择并解决问题。所有数据都保存在 MS SQL server 2005 中。

致力于解决问题的用户转到他们可以查看未解决问题的页面。因为多达 20 个人可以同时查看此页面,所以我必须解决的一个潜在问题是,如果有人在页面加载后选择了其他人选择的问题,会发生什么情况。

为了解决这个问题,我做了两件事。首先,显示要选择的问题的网格视图使用 AJAX 计时器每秒更新一次。一旦选择了一个问题,它最多会在一秒钟后消失。如果他们在这一秒内选择了一个,他们会收到一条消息,要求他们选择另一个。

问题是其中的 AJAX 部分发送了太多更新(这是我假设的),并且影响了页面和数据库的性能。此外,更新并不是每秒都在执行。我发现在触发存储过程时计时器不可靠。

必须有更好的方法,但我似乎找不到。有没有人遇到过这样的情况,或者有建议让多个用户不要选择相同的记录来维护?我真的不想完全禁用 AJAX 部分,因为我觉得单独的消息会使应用程序使用起来令人沮丧。

谢谢,

4

6 回答 6

4

在数据库中的行上放置一个锁定时间戳字段。如果过期 timsetamp 早于特定时间,则编写一个返回 true 或 false 的存储过程。将您在 Web 应用程序上的会话设置为在同一时间(一两分钟)内到期。当用户选择一行时,他们点击了存储过程,这有助于应用程序决定是否应该让用户修改它。

希望这是有道理的......

于 2008-10-27T02:50:33.477 回答
3

我做了类似的事情,一旦用户打开一张票(行),它就会将该票分配给该用户并在该记录上设置一个值,例如该特定用户的 FK,所以如果其他人试图打开该票(行)它会让他们知道它已经分配给了其他人。

于 2008-10-27T12:22:51.400 回答
3

有两件事可以帮助缓解您的问题。

首先,无论您的 ajax 更新时间框架如何,都需要在选择后通知该案例已被采纳。即使每秒检查一次也不意味着两个人不能在他们认为是同一时间点击同一个案例。在这种情况下,需要通知其中一位用户他们的选择是无效的,即使它在选择时看起来是有效的。此通知无需详细说明;即使在失望的情况下,保持轻松、有帮助的语气也可以改善用户的感知。而且,如果您已经确定了选择该记录的用户,那不仅会帮助您的用户在未来进行协调,而且还会将注意力从您的程序转移到蛇行的用户身上。(确实,管理层可能喜欢给你的用户偶尔的冲突,因为这会激励他们更快地选择案例)

其次,对如何显示案例进行小调整可以减少选择冲突。添加随机元素以显示顺序和/或过滤掉所有其他显示的案例将帮助您的用户自然地选择不同的案例。人类模式识别和任务选择并不是真正随机的,因此对表示的微小变化可能等于对选择行为的重大变化。减少碰撞机会使您的碰撞通知很少见(因此对您的用户来说不那么令人沮丧)。如果可以将您的用户分成有助于确定有用的案例排序/过滤的分类,那就更好了。

好的,随着时间的推移会帮助您的第三件事是,如果您记录碰撞发生的时间(包含有关碰撞的有用元数据,例如参与人员和选择时间)。借助可靠的碰撞数据,您可以找到有效的方法和无效的方法。随着时间的推移,您可以根据实际用例优化您的应用程序,并尽早发现潜在问题。没有什么比在他们意识到问题存在之前就已经解决问题(并且能够解释您解决问题的计划)更能让您的用户放心的了。

使用这些缓解模式,您可能会发现可以安全地缩短 ajax 查询时间,而不会影响用户体验。并且通过有用的日志记录,您将确保您所做的任何调整都在实际工作(或不工作 - 知道这可能更有用)。

于 2010-09-23T15:21:03.907 回答
2

您是否尝试过增加刷新之间的时间。我希望每 30 秒一次就足够了。40 个请求/分钟比 1200 个/分钟的负载要少得多。您的用户甚至可能没有注意到差异。

如果他们这样做了,如何在页面上提供一个刷新按钮,以便用户可以在选择项目之前手动刷新列表,以避免他们选择时出现烦人的消息。

于 2008-10-27T02:42:45.487 回答
2

如果可能的话,限制系统,让他们从工作队列中取出下一个未解决的问题,而不是让他们能够从所有未解决的问题中进行选择。

如果那是不可能的,我想你可以检查一个问题的选择,看看它是否仍然可用。如果它不可用,则在用户单击它后使其消失。这样,您仅在他们实际单击某些内容时才请求,而不是不断地轮询数据。

于 2008-10-27T02:44:06.797 回答
1

我错过了看到这个问题,特别是在您提到您已经将票证标记为正在进行/正在维护并且具有该项目的时间戳/版本之后。

以下内容还不够:

  1. 用户浏览票证并查看可用票证列表,即这不包括正在进行的数据库中的票证。如果您希望用户也看到正在进行的工单,请在工单状态中清楚地指出它并禁用接受它的选项。
  2. 用户可以通过打开工单显式或隐式地将工单标记为正在进行中(取决于用户体验/它如何呈现给用户)。
  3. 用户明确地将工单移动到不同的状态,即已完成、无效、等待反馈等。

当在 1 处检索项目时,您包括时间戳/版本。当 2 发生时,您使用乐观并发方法来确保如果 2 个人尝试同时更新 take the ticket,则只有第一个会成功。

将会发生的情况是,对于第二个人来说,更新 ... where ... timestamp = @timestamp 将找不到任何要更新的记录,并且您将报告该票已被取走。

如果您愿意,您可以在上述基础上构建,以便在抢票时更新 UI。这可能是通过在 x 时间后完全刷新当前的票证页面(可能警告/提示用户),或者甚至通过检索为使用 ajax 显示的票证页面更改的票证列表。您仍然有前面的步骤,因为此修改只是为用户提供方便。

于 2010-09-24T15:13:16.850 回答