0

我正在寻找一些关于我正在处理的问题的最佳选择的反馈。

为您提供一些背景知识，我最近继承了一个损坏的业务应用程序（我们的项目正在使用它，所以我们负责修复它），我来自 SharePoint 开发背景，所以有点 C#、ASP.NET 和 SQL。

目前我们的应用程序存在问题，我们不断收到超时错误，我已将其范围缩小到 Web 应用程序调用一堆存储过程来更新其他表中的状态字段，当某些变化可能会影响其他对象的状态时。

在不彻底检查这个应用程序的情况下，我已经确定我们最好的选择是卸载这些存储过程以在后台运行而不是绑定到 UI。我查看了几个选项，包括：

  • 创建一个单独的线程来处理执行。（仍然超时）
  • 使用 BackgroundWorker （仍然超时，显然不应该，但我似乎无法找出导致它等待 BackgroundWorker 完成的原因）
  • 将存储过程执行移动到一个作业，然后我从另一个 SP 调用它。（这可行，但限制是我一次只能运行一个作业，如果多个用户更新对象，他们会收到异常，因为作业无法启动）

现在我们已经将这些存储过程移动到每天两次的脚本中，它会更新所有对象，但这只是一个临时修复。

我正在考虑两个选项，我希望获得一些关于实施您认为是最佳选项的指导：

  • 继续使用该作业并让正在执行的存储过程在数据库中排队项目，该作业将循环通过该数据库直到为空。正在执行的存储过程必须在添加新条目时检查作业是否正在运行，然后采取相应措施。

  • 有人建议我看看使用 Service Broker，但我一点也不熟悉它的用途。我知道这可能是一个更好的整体解决方案，因为它允许我以更具事务性的方式对这些更新进行排队。

我认为这两个选项都是可行的，尽管我需要一些帮助来理解第二个选项的实施。我的另一个难题是这些存储过程在 45s 到 20m 的任何地方运行，我如何通知更改对象的用户他/她的更新已经完成？这是我回退到使用该作业的地方，因为我可以简单地将用户字段添加到“队列”中，并让存储的过程在最后发送一封快速电子邮件。

想法、建议？也许我想太多了？

4

3 回答 3

0

听起来 Service Broker 将是解决此问题的绝佳解决方案。确实，要了解它的工作原理需要一定的学习曲线，但从根本上说，它非常简单，尤其是当您的实现在单个数据库中时。

在http://msdn.microsoft.com/en-US/library/ms345108(v=SQL.90).aspx上有一个很好的（而且非常简短）介绍它是如何工作的

于 2013-05-27T22:29:22.960 回答
0

如果您在 .NET 4.5 和 C# 5.0 上使用异步，如果您在 .NET 4.0 上使用 TPL。它们具有相同的底层（几乎），并且异步功能基于 TPL（具有一些额外的内部结构）。

无论如何，TPL 将是一个合适的选择。

于 2013-05-27T21:05:50.777 回答
0

看看异步过程执行。但是如果可以改进更新，我会先看看，也许一个简单的索引可以消除超时，和/或尝试利用快照隔离。在不承诺对应用程序代码进行“大修”的情况下尝试这些会更简单。

我还必须敦促您阅读Waits and Queues。这是一种用于识别性能瓶颈的 SQL Server 方法。是一种将“超时”问题缩小到更可操作的问题（阻塞、IO、索引等）的好方法。

于 2013-05-28T16:03:51.270 回答