Handling Transient Connections in Windows Azure
Windows Azure applications will encounter dropped connections, and must be able to recover from them. This topic links to a framework for doing this.
Author: Rick Saling
Reviewers: James Podgorsky, Valery Mizonov
Handling Dropped Connections
There are a number of situations that can cause connections to be dropped in Windows Azure applications, not all of which are recoverable from. These include:
“Normal” network errors that can happen in any distributed application;
Throttling: if your application exceeds any of a variety of limits, Windows Azure SQL Database may terminate its connection;
Failover and load balancing: an application’s Azure storage and SQL Databases are duplicated multiple times. Load balancing may cause an Azure storage instance to be reconfigured, and cause a connection to the old configuration to be dropped. Failover of one SQL Database instance may cause connections to that instance to be terminated while a new instance is allocated.
The SQL Database Federations feature may likewise cause connections to be dropped as the sharding scheme in a database federation is changed.
ADO.Net Entity Framework applications that connect to a SQL Database can encounter all of the preceding situations: handling them requires some specific coding techniques.
The bottom line is that your application must be able to handle possible connection termination at any time, and recover from it. Connection termination may happen from network error conditions, but also from the normal operation of the data center. Applications must plan for this, and expect to encounter it.
Retrying Dropped Connections
Microsoft Patterns and Practices, in conjunction with the Windows Azure Customer Advisory Team, has released the Microsoft Enterprise Library 5.0 Integration Pack for Windows Azure, which contains a framework for retrying dropped connections, The Transient Fault Handling Application Block. This application block does these functions:
Determine if the dropped connection exception is one that should be retried; this alleviates the client application from having to keep track of which applications should be retried, and centralizes that logic.
Provide a range of retry strategies from which the application can choose; note that this is a choice that the developer of the application needs to make.
Execute the retry strategy that the application selected.
Throttling exceptions can have their ultimate origin in poor query design. Therefore you should first re-evaluate the design of the query when you encounter these exceptions: it may be that a redesign gains enough added efficiency to eliminate the exception.
Note that although the emphasis in the framework was initially on SQL Database connections, it also can be used with the other forms of Windows Azure storage. In addition, you can use this framework for non-cloud SQL Server databases.
Dropped Connections in Entity Framework
Entity Framework applications are abstracted from the actual SQL Database connections, and so the necessary retry code is specific to Entity Framework. However, the same retry framework can be used.
Windows Azure SQL Database and Entity Framework Connection Fault Handling is a detailed description of how to use an earlier version of this application block with Entity Framework client applications.
Other ResourcesWindows Azure SQL Database Connection Management