CODEWITHSUNDEEP
c#entity-frameworkazureazure-sql-databaseazure-sdk-.net
Rénald
Rénald

Reputation: 1430

transient fault handling with azure in a sustainable way

Azure documentation lacks and articles are often obsolete.

I've read that "Transient Fault Handling" (TFH) for Azure services (ServiceBus, FileStorage...) is now fully managed. It seems now there is nothing to implement on the client side. In the past, we could use Enterprise Library to manage such purposes but it is retired. For accessing SQL Database, a policy is implemented for Entity Framework (https://msdn.microsoft.com/en-us/data/dn456835.aspx).

Here are my questions :

We need to ensure that our components (that use WebClient, raw ADO.NET...) will run correctly in a maintanable way.

Upvotes: 4

Views: 688

Answers (1)

Gaurav Mantri
Gaurav Mantri

Reputation: 136196

I've read that "Transient Fault Handling" (TFH) for Azure services (ServiceBus, FileStorage...) is now fully managed. It seems now there is nothing to implement on the client side.

This is not correct. The service by itself will not handle transient errors. It is the responsibility of the client to handle transient errors. If you look at Storage Client Library (>= version 2.0), you will find retry policies there using which you can instruct your client code to handle transient errors.

Now coming to your questions:

Is it necessary to use Azure SDK on ServiceBus and FileStorage to benefit from policies that are now implemented on Azure ?

It is certainly not necessary to use SDKs to handle transient errors but they make your job easier. SDKs come up with a variety of ways to handle transient errors (plus you could extend the functionality available in the SDK to come up with your own transient handling strategy). To elaborate, let's consider Storage Client library which is a wrapper over Azure Storage REST API. Now this library has defined which errors should be considered transient (HTTP Status Code 500+) and which errors should not be considered transient (HTTP Status Code 400 - 499). Furthermore it comes with different kinds of retry logic - Exponential (default), Linear, or None. As a developer, you can decide what retry logic should be used in case of a transient error and bake that into your code. If you were not using these SDKs, everything needs to be done by you starting from which errors should be considered transient and how the retry should be implemented. SDKs just make your job easier.

How is it possible to manage TFH when accessing data with something that is not EF ?

If you're using ADO.Net and you get an exception, what you can do is take a look at the ErrorCode returned by the service and determine if the error is transient or not. For a list of SQL Error Codes, please see this link: https://azure.microsoft.com/en-in/documentation/articles/sql-database-develop-error-messages/. I would also highly recommend reading this article as well as to how you would go about implementing your own TFH: https://azure.microsoft.com/en-in/documentation/articles/sql-database-connectivity-issues/.

Upvotes: 5

Related Questions