将LINQ to SQL迁移到SQL Azure的最简单方法：添加重试逻辑。

Question

我有几个现有的ASP .NET Web表单和MVC应用程序，目前使用LINQ to SQL和Windows VPS上的SQL Server 2008 Express数据库：一个VPS同时承载IIS和SQL。我开始发现VPS无法有效地托管SQL和IIS，因此准备将它们分开。我考虑将数据库迁移到SQL Azure，并保留IIS在VPS上。

经过初步研究，当采用SQL Azure时，在数据访问层中实现重试逻辑是必须的。我怀疑在我的情况下，IIS将位于Azure基础架构之外的VPS上，这更加关键。

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

- Pat James

---

我也在SQL Azure的MSDN论坛上发布了这个问题。那里的回复基本上是“不要这样做，SQL Azure不适合这种架构”。 - Pat James

Answer 1

我认为这个问题并不需要复杂化。将整段代码放在 try catch 中，再用 while < 重试次数 就可以完成了。

如果你想要根据错误类型进行不同处理，那么可以更加智能地捕获不同类型的错误。例如，如果是真正的数据错误，则无需重试。

但是一定要确保每个异常都仍然被 Trace 输出，以便除超时之外的其他错误。

- Doobi

---

整个东西包裹起来？我的代码中每一个创建新数据库连接的实例...那会有很大的影响。 - Pat James

很抱歉，我认为不存在现有的重试快捷方式。不过你可以创建一个IQueryable扩展方法，将查询进行包装并返回。 - Doobi

以下是有关打开连接的热点的一些指导。我建议创建它们的替代扩展方法：http://msdn.microsoft.com/en-us/library/bb896325.aspx - Doobi

Answer 2

你可以查看面向切面编程（AOP）框架，以最小的努力管理重试逻辑。其中一个这样的框架是AspectF，它松散地实现了AOP原则。它易于理解和使用。

- Chandermani

Answer 3

基本原则是，对于任何因不再成立的原因而失败的事务，都要重试。所以，如果事务由于死锁或与数据库服务器的错误连接而失败，您应该在每次重试之间进行短暂休眠并尝试几次。所有这些都取决于您的交易是否定义清楚。

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

• 这取决于能否安全地重新执行页面请求的工作，或者完整的页面请求处理过程是否在数据库事务内部。
• 还要考虑服务器上保留的任何内存状态。
• 添加到页面处理管道的 HttpHander 应能够为所有页面执行此操作。

我认为，如果您没有明确定义交易，则无法在代码上施展任何“魔法”来解决此问题。

如果您没有使用任何交易，可以尝试编写所有 SQL 使其可以安全地运行任意次数，然后只需具有在需要时重试的自定义命令对象的子类即可。

- Ian Ringrose