在LINQ to SQL迁移到SQL Azure时改进重试逻辑的最简单方法

Question

我有几个现有的ASP表单和MVC应用程序，它们目前在Windows VPS上使用LINQ to SQL和SQL Server2008Express数据库:一个VPS用于.NET和SQL。我开始超出VPS有效地托管SQL和IIS的能力，并准备将它们分开。我正在考虑将数据库迁移到SQL Azure，并将IIS保留在VPS上。

经过初步研究，在采用SQL Azure时，在数据访问层实现重试逻辑似乎是必须要做的事情。我怀疑在我的情况下，IIS将在Azure基础设施之外的VPS上实现这一点甚至更加关键。

我正在寻找关于如何用最少的努力和对我现有代码库的影响来做这件事的指针。是否有一个好的重试模式可以在LINQ to SQL数据访问层应用一次，而不必将所有LINQ to SQL操作包装在try/catch/wait/retry逻辑中？

Answer 1

在这个问题上，我不认为有必要变得复杂。把整个东西包装在一个try catch中，在一段时间内包装它< retry count，你就完成了。

你可以为不同类型的错误获取一个大的智能陷阱，如果你想以不同的方式处理它们，如果这是一个真正的数据错误，不需要重试。

确保您仍然跟踪每个异常，以跟踪除超时之外的其他错误。

Answer 2

您可以查看面向方面编程(AOP)框架，以便以最小的工作量管理重试逻辑。AspectF就是这样一个框架，它松散地实现了面向方面编程的原则。它很容易理解和使用。

Answer 3

基本原则是重试任何由于可能不再正确的原因而失败的事务。因此，如果事务由于死锁或到数据库服务器的错误连接而失败，则应该在每次重试之间进行排序休眠来重试几次。这一切都取决于您的事务是否定义良好，。

根据您的逻辑，您可以在“页面请求级别”实现重试。

• 这取决于是否可以安全地重做页面请求所做的工作，或者为了使页面请求在数据库中的完整进程，请考虑您保留在服务器上的任何内存状态。
• 添加到页面处理管道中的HttpHander应该能够对所有页面执行此操作

如果你没有定义明确的事务，我不认为在你的代码中有任何“你可以旋转的魔法”来解决这个问题。

如果您没有使用任何事务，您可以尝试编写所有的sql，这样就可以安全地运行任意次数的sql，然后只需拥有一个自定义的command对象子类，以便在需要时重新绑定。