Connection Resiliency and Command Interception are two great features of Entity Framework. Retrying connection in case of network/ connection failure refers to connection resiliency and intercepting what entity framework passes and receives to/from underlying DB is known as command interception.

1. Connection Resiliency & Command
Interception

2. Connection Resiliency

3. 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.

4. 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 network
causing intermittent timeouts and other transient errors.

5. 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.

6. 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).

7. 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.

8. Execution Strategies in EF
• Connection retry is taken care of by an implementation of the
IDbExecutionStrategy interface. Implementations of the IDbExecutionStrategy
will 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

9. 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 DbExecutionStrategy
and will retry on exceptions that are known to be possibly transient when working with
SqlAzure.

10. Configuring Execution Strategy in EF
• This code tells EF to use the SqlAzureExecutionStrategy when connecting to SQL
Server.

11. 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

12. Command Interception

13. 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.

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

15. 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 and
ExecuteReader operations to the database.

16. Interception interface (Contd.)

17. 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.

18. 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.

19. 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.

20. 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.

21. 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.

22. Configuring Interceptor

23. 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