Dijelite putem


The Design of the Transient Fault Handling Application Block

Retired Content

This content and the technology described is outdated and is no longer being maintained. For more information, see Transient Fault Handling.

patterns & practices Developer Center

On this page:
Design Highlights | SQL Azure

The Transient Fault Handling Application Block is designed to achieve the following goals:

  • To encapsulate the logic for retrying service operations that may encounter transient fault conditions.
  • To allow retry strategies to be defined in configuration or code.
  • To work with the Data Access Application Block.
  • To enable the developer to create extensions to the default transient fault handling functionality.

This topic covers the design of the Transient Fault Handling Application Block, describing the highlights.

Design Highlights

The following diagram illustrates the key classes in the Transient Fault Handling Application Block.

Follow link to expand image

Key classes and interfaces in the Transient Fault Handling Application Block

The Transient Fault Handling Application Block is split into three assemblies: TransientFaultHandling and TransientFaultHandling.Core, as shown in the diagram, and TransientFaultHandling.Configuration, which provides design-time configuration support. The TransientFaultHandling.Core assembly has no dependencies on any other Enterprise Library assemblies and can be used independently of Enterprise Library and the Transient Fault Handling Application Block.

Typically, the client application obtains a reference to a RetryManager instance by using the EnterpriseLibraryContainer in a manner similar to other Enterprise Library blocks. The RetryManager class returns a RetryPolicy instance to the client. The RetryManager class is also responsible for loading retry strategies from the configuration.

The client app can also obtain a reference to a RetryPolicy instance by using the RetryPolicyFactory class. This approach is provided for backwards compatibility with the Transient Fault Handling Application Framework.

Note

Clients can also instantiate a RetryPolicy instance directly. However, in this scenario the client cannot take advantage of the configuration features of the block.

The client uses the RetryPolicy instance to wrap the call that requires retry logic. The RetryPolicy class provides several overloaded versions of the ExecuteAction method for this purpose. These overloaded versions handle the common scenarios for making calls to services.

A RetryPolicy object comprises a detection strategy for the service being used by the client application and a retry strategy defined by the developer.

The block includes the following detection strategy classes that implement the ITransientErrorDetectionStrategy interface.

  • StorageTransientErrorDetectionStrategy. Provides the transient error detection logic that can recognize transient faults when dealing with Microsoft Azure storage services.
  • CacheTransientErrorDetectionStrategy. Provides the transient error detection logic that can recognize transient faults when dealing with Azure Caching Service.
  • ServiceBusTransientErrorDetectionStrategy. Provides the transient error detection logic that can recognize transient faults when dealing with Azure Service Bus.
  • SqlAzureTransientErrorDetectionStrategy. Provides the transient error detection logic for transient faults that are specific to SQL Azure.

The Transient Fault Handling Application Block includes the following retry strategies that extend the RetryStrategy class.

  • FixedInterval
  • Incremental
  • ExponentialBackoff

The FixedInterval retry strategy retries an operation a fixed number of times at fixed intervals.

The Incremental retry strategy retries an operation a fixed number of times at intervals that increase by the same amount each time. For example, at two-second, four-second, six-second, and eight-second intervals.

The ExponentialBackoff retry strategy retries an operation a fixed number of times at intervals that increase by a greater number each time. For example, at two-second, four-second, eight-second, and sixteen-second intervals. This retry strategy also introduces a small amount of random variation into the intervals.

SQL Azure

The Transient Fault Handling Application Block also includes a class called ReliableSqlConnection and two static SQL Azure extension classes called SqlCommandExtensions and SqlConnectionExtensions to facilitate working with SQL Azure.

The ReliableSqlConnection class is designed to use as a replacement for the standard SqlConnection class in the .NET Framework. It includes methods that you can use to reliably establish connections and execute commands against a SQL Azure database.

In addition, the SqlCommandExtensions and SqlConnectionExtensions classes provide a set of extension methods that enable .NET developers to open SQL Azure database connections and invoke the SQL commands. These extension methods are useful in the event that you are unable to adapt your code to take advantage of the ReliableSqlConnection class. For example, you may be using the Enterprise Library Data Access Application Block or Entity Framework that use SqlConnection instances internally. In this case, the extension methods help you add the retry capabilities offered by the Transient Fault Handling Application Block to the existing code without major re-work.

Next Topic | Previous Topic | Home

Last built: June 7, 2012