【问题标题】:WCF RIA Services and SQL Azure transient fault handlingWCF RIA 服务和 SQL Azure 瞬态故障处理
【发布时间】:2025-12-17 11:35:01
【问题描述】:

在使用由 Entity Framework 和/或 Linq to SQL 支持的 WCF RIA 服务时,是否有任何已发布的指南来处理 SQL Azure 中的瞬态故障场景?

我们研究了 CAT 重试库 (Transient Fault Handling Framework for SQL Azure) 和文档 (Retry Logic for Transient Failures in SQL Azure),尤其是与 Entity Framework 和 Linq to SQL 相关的部分。

例如,在 Linq to SQL 的情况下,我们被指示将查询/更新代码包装到 ExecuteAction 中并使用 RetryPolicy 执行它。

这篇文章 (Silverlight 4, EF 4, RIA Services & Windows Azure together) 表明,我们所能期望的最好的结果就是增加连接的弹性。但是,我们似乎可以通过覆盖 LinqToEntitiesDomainService 和 LinqToSqlDomainService 上的 PersistChangeSet 方法并在那里添加我们的重试来获得我们想要的结果。

例如(伪代码)

 protected override bool PersistChangeSet()
 {
    e.Result = retry.ExecuteAction(() =>
        {
            return base.PersistChangeSet();
        });

    return e.Result;
 }

对这种方法有什么想法吗?是否有任何文档或指南,特别是与 RIA 服务相关的?

【问题讨论】:

  • ria 服务和实体框架是否存在特定问题? Ria 服务似乎是一个与实体框架的重试问题无关的实现细节。

标签: error-handling wcf-ria-services azure-sql-database


【解决方案1】:

这本来是一个评论,但是...

我最近在实体框架中使用了RetryPolicy类,没有遇到任何问题。 添加重试非常简单且影响很小。

链接的文章日期(5 月 30 日)是在他们向企业库添加对 azure 的支持之前。 (see this announcement)

因此,基于上述场景,我会说 RetryPolicy 将满足所描述的要求。

【讨论】:

  • 谢谢。似乎 RetryPolicy 在进行更新时非常适合(请参阅问题中的 PersistChangeSet ),尽管我没有对此进行测试。在读取的情况下,我们有数百个查询,并且在重试中包装每一个查询是一项艰巨的任务。此外,在大多数情况下,查询是“延迟的”——也就是说,读取返回 IQueryables。如何处理这种情况?集成的故事并不完整,就像 ADO.NET 一样,尽管我同意这些是 EF 特定的而不是 RIA 服务特定的。
  • 您的问题暴露了 EF 和当前 ent 库的问题之一。您最终会在代码的表层中使用重试逻辑。我认为应该有一个非常低级别的委托,您可以在 ado.net 中订阅,以便实现这种类型的逻辑的设置很容易在单点注入。据我所知,没有这种方法。