Can the SqlServerTransientExceptionDetector be moved to System.Data.SqlClient?

From @avantida on October 18, 2018 8:17

The SqlServerTransientExceptionDetector class is really handy to detect if a Sql operation needs to be retried while building anything based on a SqlConnection. It basically is the core component driving the SqlServerRetryingExecutionStrategy of .NET EF Core. (which used to be the AzureSqlExecutionStrategy in EF)

This logic is sort of replicated also in the Enterprise Library Transient Fault Handling Application Block and then again even in the Elastic database tools for Azure SQL Database

Moving this code ‘upstream’ would aid a lot to enable reliable operation with Azure Sql with any of the SQL compatible .NET Core Data Access tools out there.

Today we’re not falling in the pit of success to run our code on Azure. (We’re using Dapper @NickCraver )

Copied from original issue: aspnet/EntityFrameworkCore#13665

[Plasma]

Really supportive of having this in the base package (or an extension package) with a production-ready integration working. The guidance on Azure website and MSDN is a total mess.

• There was originally reference to TOPAZ library and ReliableSqlConnection, that is now obsolete.

• The Azure docs provide a range of error codes to be retried, https://docs.microsoft.com/en-us/azure/sql-database/troubleshoot-connectivity-issues-microsoft-azure-sql-database#transient-fault-error-messages with no clear production-ready strategy to handle them (just wrap connection.Open? What about command execution? What about pooled connections?).

• As mentioned in this ticket, there are multiple implementations of the same logic, but are tied to the higher-level frameworks (Elastic pools, EF) instead of being based on the low-level client

• When SqlConnection was updated to support retries, it was flagged as the replacement of ReliableSqlConnection, but it doesn’t actually work well, so back to square one.

• SqlConnection and other classes are sealed, making it difficult to override methods to support some kind of retry, so the reliable connection can be provided to 3rd party code that expects SqlConnection etc

Any suggestions about where and how the retry logic should be placed for production-ready code would be appreciated, but going forward, this being built-in to the package itself would be ideal.

[avantida]

@roji Thanks for the heads up, read the (rather long) discussion there. And I agree that to be the way forward, and unfortunately with Azure SQL it still is required. It would indeed be a lot better if Azure SQL could handle the resilience better server-side, but I’m assuming this has historical and deep architectural reasons, not easily remediated.

I was also not aware of the ConnectRetry* properties for the connectionstring, and we will also give that a try.