Transient Fault Handling Framework for SQL Azure, Windows Azure Storage, Service Bus & Cache

The Transient Fault Handling Framework has been superseded by a newer deliverable from the Patterns & Practices team. It is now called the Transient Fault Handling Application Block and comes in all 3 flavors:

The new Transient Fault Handling Application Block is now our officially recommended approach to handling transient faults in the applications running on the Windows Azure platform.

Please share any feedback, comments or suggestions for improvements. You can get in touch with us via:

1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 5.00 out of 5)

23 Comments

  1. Pingback: AppFabric CAT | Reliable Retry Aware BCP for SQL Azure

  2. Pingback: Implementing Storage Abstraction Layer to Support Very Large Messages in Windows Azure Queues | AppFabric CAT

  3. Adam Pluciński
    August 25, 2011 at 3:18 am

    Sample code looks solid- please make from it some framework for transient operations.
    …and please do not reinvent the wheel with HighResolutionTimer -> same implementation is in System.Diagnostics.Stopwatch class

  4. Valery Mizonov
    August 25, 2011 at 10:23 am

    Feedback taken, thanks. One comment though – the reason why HighResolutionTimer is there is due to Stopwatch being suboptimal for the given use case.

  5. Pingback: Windows Azure and //BUILD/ Posts for 9/12/2011+ - Windows Azure Blog

  6. Pingback: DavidAiken » Implementing Windows Azure Retry Logic

  7. Bruce Kim
    October 17, 2011 at 12:12 am

    I suggest a small change to the method “public T ExecuteCommand(IDbCommand command, RetryPolicy retryPolicy, CommandBehavior behavior)” on lines 268-272 to add a check if the type parameter is “object”. This is to permit the case of invoking the ExecuteScalar method when you don’t know the return type in advance. Without the added check the resultType.IsAssignableFrom(typeof(IDataReader)) check returns true and the code incorrectly assumes you are trying to invoke the ExecuteReader method.

    The changes lines are as follows:

    if (resultType.IsAssignableFrom(typeof(IDataReader)) && (resultType != typeof(object)))
    {
    return (T)command.ExecuteReader(behavior);
    }
    else if (resultType.IsAssignableFrom(typeof(XmlReader)) && (resultType != typeof(object)))

  8. Valery Mizonov
    October 17, 2011 at 7:25 am

    Hi Bruce,

    Thanks for the feedback, makes total sense.

    The change will be made and the updated package will be published in the upcoming days.

  9. Pingback: Windows Azure Best Practices - Nuno Filipe Godinho

  10. Pingback: Windows Azure Best Practices (PT/EN) - Nuno Filipe Godinho

  11. Tom McKearney
    October 26, 2011 at 5:33 am

    The current NuGet package references the Microsoft.ServiceBus version 1.0.0.0. The current SDK version is 1.5.0.0… I get compiler warnings because of this.

    Are you guys planning on upgrading the package?

  12. Valery Mizonov
    October 28, 2011 at 7:38 pm

    Hi Tom!

    I have just uploaded a new NuGet package with the support for the latest SDK for Service Bus.

  13. Rasmus Mikkelsen
    November 15, 2011 at 4:00 am

    Hi

    I’m doing a proof-of-concept project to see if we should use the framework in our product, but I get the following error:

    Assembly generation failed — Referenced assembly ‘Microsoft.AzureCAT.Samples.TransientFaultHandling’ does not have a strong name

    Could you sign it?

    P.S.: I use the version from NuGet.

  14. Valery Mizonov
    November 15, 2011 at 10:54 am

    Will do.

  15. Charles Lee
    December 20, 2011 at 4:14 am

    it sounds great, are you going to produce the similar for ODBC driver? as our application is using ODBC to talk to SQL Azure.

  16. Hari
    December 30, 2011 at 1:08 am

    Does Transient Fault Handling application block is smart enough to know what type of exceptions to be retried or developer is responsible for using the retry policies only for those exceptions that are of application’s interest?

  17. David
    February 7, 2012 at 6:41 pm

    ExecuteAction() works great for reads. I am, however, worried about writes to the database. Consider the following pseudo-code:

    try
    {
    OpenConnection;
    Begin Transaction;
    Update 1;
    Update 2;
    Commit Transaction;
    }
    catch
    {
    Rollback Transaction;
    }

    The easiest way of making this resilient is by making use of ExecuteAction() on the updates (for example, SqlCommand’s ExecuteNonQueryWithRetry). My only concern is that updates have effects on the data. If the update is calling a long sproc and I get a timeout, what did actually happen? Did my sproc succeed? Did it partially succeed? It will be horrible to retry the update a second time if it was the case. It seems like a more robust pattern would to wrap the entire piece of code in ExecuiteAction() instead. Thoughts?

  18. Valery Mizonov
    February 8, 2012 at 8:33 am

    Charles, Hari, David,

    First, please accept my apology for the delayed response. Our team was very busy lately.

    Please may I suggest you post your questions on the discussion forum here:

    http://entlib.codeplex.com/discussions

    This will ensure a timely response. Your questions are very valuable and it would make sense to use a public forum so that other folks can learn from your challenges or suggest potential solutions.

    Regards,
    Valery

  19. Pingback: Windows Azure and Cloud Computing Posts for 4/28/2012+ - Windows Azure Blog

  20. Pingback: Using The Exponential Back-Off Transient Error Detection Strategy « Alexandre Brisebois

  21. Pingback: 33 Windows Azure Best Practices | Aditi Technologies

  22. Pingback: Defining an HTTP Transient Error Detection Strategy For REST Calls | Alexandre Brisebois

  23. Pingback: 33 Windows Azure Best Practices | Aditi Technologies Blog

Leave a Reply