In addition to network blips. services like Azure SQL can dynamically reconfigure themselves<\/a> in response to situations like heavy workloads, planned events (like software upgrade or maintenance) and unplanned issues, like hardware or software failures. When events like these happen, client applications can lose connection to the database and receive specific error codes providing an indication of what’s going on in the system. To get a comprehensive list of error messages that can usually be considered as transient and retriable, we recommend you take a deeper look at this other article<\/a>.<\/p>\n Over the last few years, we provided guidance<\/a> on how customers could create their own retry logic or, as an alternative, reuse existing libraries aimed to simplify this task for them, More recently, we decided to provide a better experience by incorporating configurable retry logic capabilities directly in our client drivers portfolio<\/strong> starting with Microsoft.Data.SqlClient<\/a> for .NET 5, .NET Core and full .NET Framework (although we’re planning to cover other major drivers like JDBC, ODBC and more over the next months).<\/p>\n In essence, configurable retry logic lets developers and app managers specify, through code or app config files, how operations like opening a connection or executing a command should react when they encounter a connectivity issue manifesting itself with a certain exception number considered transient or “retriable”. In addition to error codes treated as transient (those published in this list<\/a>), they can also add new error codes that are part of their business logic through the configuration file and specify regular expression patters of commands that should be considered or excluded from automatic retries, without writing a single line of code for that.<\/p>\n Digging down into details, this new feature is composed by three main components:<\/p>\n The Core API itself is designed around these three interfaces:<\/p>\n As this is an extensible design, application developers with very peculiar requirements can create their own retry logic provider, containing a custom implementation of these concrete classes, where specify all the details of how operation will be retried.<\/p>\n For most developers though, they can just use the default base provider that offers out-of-the-box implementation of most common retry patterns like fixed, incremental and exponential retry intervals.<\/p>\n By adding a reference to Microsoft.Data.SqlClient v3.0 Preview NuGet package in your existing project, and creating specific sections in your configuration file, you can enable Retry Logic by turning on the safety switch we have during Preview<\/strong> phase and define what retry method you want to use for SqlConnection and SqlCommand operations like connection opening and command execution.<\/p>\n Here’s an example of such a configuration file:<\/p>\n Once .NET AppContext safety switch is on, you can define a retry logic for SqlConnection and SqlCommand independently, together with a set of options like:<\/p>\n The value of retryMethod<\/em> attribute determines which enumerator is used to generate time intervals:<\/p>\n The approach based on configuration file is great for those who are interested in getting automatic retry logic out-of-the-box without the need for changing a single line of code in their applications: they just need to add a reference to the new SqlClient package, recompile and voil\u00e0!<\/p>\n If instead you’re developing a brand-new application and want to get the most of all the available retry logic behaviors and settings, you can reuse the base classes now available and configure your own retry logic based on your requirements<\/strong>.<\/p>\n Here is an example of how to configure retry logic options and create a new provider to assign to a SqlConnection instance:<\/p>\n When executed against an Azure SQL Database with firewall rules blocking this client machine (this is where the error code 40615 is coming from), here is the result:<\/p>\n As you can see, connection opening has been retried for 3 times before returning an exception to the application.<\/p>\n As a side note, you can see that despite DeltaTime<\/em> property was set to 10 seconds, the real delay before retries can be slightly shorter or longer. This is because we’re introducing a small random delay (or anticipation) to make sure that, in case multiple clients are trying to connect using the same retry logic, not all of them are hitting the backend database at the same exact time, causing potential concurrency issues.<\/p>\n For new, cloud-native data applications using Azure SQL as backend database, having a configurable (and extensible) retry logic framework baked into client drivers like Microsoft.Data.SqlClient is critical to create a more reliable user experience and respond to unexpected connectivity issues.<\/p>\n For existing applications moving to the cloud, the ability to add automatic retry logic by just configuring few sections in the app config file will remove many barriers and simplify migration projects of all sizes.<\/p>\nIntroducing Configurable Retry Logic<\/h4>\n
\n
\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-content\/uploads\/sites\/56\/2021\/03\/Screenshot-2021-03-09-174247.png\")
<\/a><\/p>\nHow to use Configurable Retry Logic?<\/h4>\n
<?xml version=\"1.0\" encoding=\"utf-8\" ?>\r\n<configuration>\r\n <configSections>\r\n <section name=\"SqlConfigurableRetryLogicConnection\"\r\n type=\"Microsoft.Data.SqlClient.SqlConfigurableRetryConnectionSection, Microsoft.Data.SqlClient\"\/>\r\n <section name=\"SqlConfigurableRetryLogicCommand\"\r\n type=\"Microsoft.Data.SqlClient.SqlConfigurableRetryCommandSection, Microsoft.Data.SqlClient\"\/>\r\n\r\n <section name=\"AppContextSwitchOverrides\"\r\n type=\"Microsoft.Data.SqlClient.AppContextSwitchOverridesSection, Microsoft.Data.SqlClient\"\/>\r\n <\/configSections>\r\n\r\n <!--Enable safety switch in .NET Core-->\r\n <AppContextSwitchOverrides value=\"Switch.Microsoft.Data.SqlClient.EnableRetryLogic=true\"\/>\r\n\r\n <!--Retry method for SqlConnection-->\r\n <SqlConfigurableRetryLogicConnection retryMethod =\"CreateFixedRetryProvider\" numberOfTries =\"3\" deltaTime =\"00:00:10\" maxTime =\"00:00:30\"\r\n transientErrors=\"40615\" \/>\r\n\r\n <!--Retry method for SqlCommand containing SELECT queries-->\r\n <SqlConfigurableRetryLogicCommand retryMethod =\"CreateIncrementalRetryProvider\" numberOfTries =\"5\" deltaTime =\"00:00:10\" maxTime =\"00:01:10\"\r\n authorizedSqlCondition=\"\\b(SELECT)\\b\" transientErrors=\"102, 4060, 0\"\/>\r\n<\/configuration><\/pre>\n
\n
\n
class Program\r\n {\r\n static void Main(string[] args)\r\n {\r\n AppContext.SetSwitch(\"Switch.Microsoft.Data.SqlClient.EnableRetryLogic\", true);\r\n SqlRetryLogicOption rto = new SqlRetryLogicOption() { NumberOfTries = 3, DeltaTime = TimeSpan.Parse(\"00:00:10\"), MaxTimeInterval = TimeSpan.Parse(\"00:00:30\"), TransientErrors = new[] { 40615 } };\r\n SqlRetryLogicBaseProvider prov = SqlConfigurableRetryFactory.CreateFixedRetryProvider(rto);\r\n using (SqlConnection cnn = new SqlConnection(\"server=.;\"))\r\n {\r\n cnn.RetryLogicProvider = prov;\r\n cnn.RetryLogicProvider.Retrying += new EventHandler<SqlRetryingEventArgs>(OnRetrying);\r\n\r\n cnn.Open();\r\n }\r\n }\r\n\r\n protected static void OnRetrying(object sender, SqlRetryingEventArgs args)\r\n {\r\n Console.WriteLine(\"Retrying for {0} times for {1:0.00} sec - Error code: {2}\", args.RetryCount, args.Delay.TotalMilliseconds\/1000.0, (args.Exceptions[0] as SqlException).Number);\r\n }\r\n }<\/pre>\n![\"Image](\"https:\/\/devblogs.microsoft.com\/azure-sql\/wp-content\/uploads\/sites\/56\/2021\/03\/Screenshot-2021-03-09-164550.png\")
<\/a><\/p>\nScenarios where configurable retry logic can be a game changer<\/h4>\n