Connection Resiliency & Command Interception

Connection Resiliency

Problem

• Applications connecting to a database server have always been vulnerable to connection breaks due to back-end failures and network instability.

• However, in a LAN based environment working against dedicated database servers these errors are rare enough that extra logic to handle those failures is not often required.

Cause of Problem

• With the rise of cloud based database servers such as Windows Azure SQL Database and connections over less reliable networks it is now more common for connection breaks to occur.

• This could be due to defensive techniques that cloud databases use to ensure fairness of service, such as connection throttling, or to instability in the networkcausing intermittent timeouts and other transient errors.

Connection Resiliency / Retry Logic in EF

• Connection Resiliency refers to the ability for EF to automatically retry any commands that fail due to these connection breaks.

Why Connection Resiliency and Command Interception?

• Two features of Entity Framework 6 that are especially valuable when you are deploying to the cloud environment:

• connection resiliency (automatic retries for transient errors) and

• command interception (catch all SQL queries sent to the database in order to log or change them).

Configuring Connection Resiliency Features

The connection resiliency feature must be configured appropriately for a particular database service:

• It has to know which exceptions are likely to be transient. You want to retry errors caused by a temporary loss in network connectivity, not errors caused by program bugs, for example.

• It has to wait an appropriate amount of time between retries of a failed operation. You can wait longer between retries for a batch process than you can for an online web page where a user is waiting for a response.

• It has to retry an appropriate number of times before it gives up. You might want to retry more times in a batch process that you would in an online application.

Execution Strategies in EF

• Connection retry is taken care of by an implementation of the IDbExecutionStrategy interface. Implementations of the IDbExecutionStrategywill be responsible for accepting an operation and, if an exception occurs, determining if a retry is appropriate and retrying if it is.

• There are four execution strategies that ship with EF:• DefaultExecutionStrategy

• DefaultSqlExecutionStrategy

• DbExecutionStrategy

• SqlAzureExecutionStrategy

Execution Strategies in EF (Contd.)

• DefaultExecutionStrategy: this execution strategy does not retry any operations, it is the default for databases other than SQL server.

• DefaultSqlExecutionStrategy: this is an internal execution strategy that is used by default. This strategy does not retry at all, however, it will wrap any exceptions that could be transient to inform users that they might want to enable connection resiliency.

• DbExecutionStrategy: this class is suitable as a base class for other execution strategies, including your own custom ones. It implements an exponential retry policy, where the initial retry happens with zero delay and the delay increases exponentially until the maximum retry count is hit. This class has an abstract ShouldRetryOn method that can be implemented in derived execution strategies to control which exceptions should be retried.

• SqlAzureExecutionStrategy: this execution strategy inherits from DbExecutionStrategyand will retry on exceptions that are known to be possibly transient when working with SqlAzure.

Configuring Execution Strategy in EF

• This code tells EF to use the SqlAzureExecutionStrategy when connecting to SQL Server.

REFERENCES

• http://msdn.microsoft.com/en-us/data/dn456835.aspx

• http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/connection-resiliency-and-command-interception-with-the-entity-framework-in-an-asp-net-mvc-application

• http://channel9.msdn.com/Events/Visual-Studio/Launch-2013/LB104

• http://entityframework.codeplex.com/wikipage?title=Connection%20Resiliency%20Spec

• http://www.codeproject.com/Tips/758469/Implementing-Connection-Resiliency-with-Entity-Fra

Command Interception

Command Interception in EF

• The high-level goal for the interception feature is to allow external code to observe and potentially intercept EF operations.

• Anytime Entity Framework sends a command to the database this command can be intercepted by application code.

Usage of Command Interception

• This is most commonly used for logging SQL, but can also be used to modify or abort the command.

Interception interface

• The interception code is built around the concept of interception interfaces.

• EF 6 provides the ability to intercept the context using IDbCommandInterceptor, before and after it performs the ExecuteNonQuery, ExecuteScalar andExecuteReader operations to the database.

Interception interface (Contd.)

Interception Context

• The object DbInterceptionContext contains contextual information about the action that EF is taking.

• For example, if the action is being taken on behalf of a DbContext, then the DbContext is included in the DbInterceptionContext. Similarly, for commands that are being executed asynchronously, the IsAsync flag is set on DbCommandInterceptionContext.

Interception Result handling

• The DbCommandInterceptionContext class contains four properties

• Result

• OriginalResult

• Exception

• OriginalException.

• If the operation is executed and succeeds, then Result and OriginalResult are set to the result of the operation. Likewise, if the operation throws, then the Exception and OriginalException properties will be set.

Interception Suppressing execution

• If an interceptor sets the Result property before the command has executed (in one of the …Executing methods) then EF will not attempt to actually execute the command, but will instead just use the result set and continue as if the command had been executed.

• Execution can also be suppressed by setting the Exception property in one of the …Executing methods. This causes EF to continue as if execution of the operation had failed by throwing the given exception.

• For example, this could be used in test environments to test the behavior of an application when command execution fails.

Interception: Changing the result after execution

• If an interceptor sets the Result property after the command has executed (in one of the …Executed methods) then EF will use the changed result instead of the result that was actually returned from the operation.

• Similarly, if an interceptor sets the Exception property after the command has executed, then EF will throw the set exception as if the operation had thrown the exception.

Interception: OriginalResult and OriginalException

• The OriginalResult and OriginalException properties are

• read-only

• only set by EF

• These properties cannot be set by interceptors. This means that any interceptor can distinguish between an exception or result that has been set by some other interceptor as opposed to the real exception or result that occurred when the operation was executed.

Configuring Interceptor

REFERENCES

• http://msdn.microsoft.com/en-us/data/dn469464

• http://www.entityframeworktutorial.net/EntityFramework6/database-command-interception.aspx

• http://entityframework.codeplex.com/wikipage?title=Interception