ADO.NET的弹性连接控制[ADO.NET idle connection resiliency]
ADO.NET连接SQL Server有时候联机会无故的中断 (例如闲置过久或是交易时间太长等因素),这时又要重新连接,在.NET Framework 4.5之前,这件事情要由开发人员自己依照ADO.NET的SqlException来判断并自行重试,重试的算法也要由开发人员来自定义,所以SQL Database的CAT (Customer Advisory Team) 开发了Transient Fault Framework给Windows Azure的开发人员使用,而.NET Framework 4.5.1则正式将它纳入ADO.NET的核心程序代码中,能够断开会话状态并在适当的时候恢复会话,很多场景都会收益于这个功能.
ADO.NET Idle Connection Resiliency这个功能被包装在Entity Framework 6中,在DbConfiguration设定DbExecutionStrategy对象,Entity Framework 6内建了四种不同的DbExecutionStrategy[http://msdn.microsoft.com/pt-BR/data/dn456835],分别是:
类
说明
DefaultExecutionStrategy
执行时不包含重试策略,这会自动用于SQL Server以外的数据库。
DefaultSqlExecutionStrategy
执行时不包含重试策略,但是它会包装例外状况,由使用者决定是否要启用Connection Resiliency。
DbExecutionStrategy
这个对象是所有执行策略的基础类别,它包装了指数式重试原则 (exponential retry policy) 算法,并且由实作来决定要如何使用这个算法,以及重试的次数等。
SqlAzureExecutionStrategy
专为SQL Azure Database设计的重试策略,会依照已知的可能瞬断问题进行自动的重试处理。
上文提到的 Transient Fault Framework 其实Enterprise Library的一个模块。这个框架考虑到了处理所有可能的瞬态错误的需求,在内部实现了一个“Retry Policy”来确保只处理需要的错误。在客户进入重试状态前会使用策略验证这个异常是否属于瞬态错误。
提供了一个可扩展的Retry逻辑处理瞬态错误,不仅限于SQL Server。 支持一系列的重试方案(固定周期,渐进周期,随机指数退避) 支持SQL 连接和SQL命令使用不同的Retry策略。 为SqlConnection 和SqlCommand对象提供了扩展方法来实现Retry操作 支持Retry后的回调,通知用户代码是否发生了Retry情况 支持快速重试模式,当第一次发生进行Retry时会立即尝试而没有延迟 允许在应用程序配置文件中定义Retry策略 支持同步和异步请求下面是几个类似的项目:
SQL Fault Retry Provider提供了一个如何创建高可用性应用程序的案例,当然特指在SQL Mirroring环境下。并且提供了一个可以进行重试操作的 Data Provider. Endjin Retry Framework:提供了一下TPL的 重试框架 Polly: 提供了一个.NET 3.5/4.0/4.5 下都可用的重试库 通过nuget上 查询retry可以查到很多相关的项目 https://www.nuget.org/packages?q=retry
译文:SQL Azure客户端-瞬态错误处理最佳实践
基于Enterprise Library 6 的AOP实现
声明:本站所有文章资源内容,如无特殊说明或标注,均为采集网络资源。如若本站内容侵犯了原著者的合法权益,可联系本站删除。