ReliableSqlConnection and EnterpriseLibraryContainer

Topics: Windows Azure Integration Pack
Apr 20, 2012 at 10:59 PM

Why does creating a ReliableSqlConnection(string, RetryPolicy) require the use of the EnterpriseLibraryContainer?  It seems that I should be able to create a ReliableSqlConnection without needing to use the Enterprise Library infrastructure, but this does not appear to be the case.  Any insights as to why?

Apr 23, 2012 at 5:31 AM
Edited Apr 23, 2012 at 5:35 AM

From a technical implementation point of view the reason for the use of the container is that the constructor ReliableSqlConnection(string, RetryPolicy) is only specifying the connection retry policy and not the command retry policy.  So, ReliableSqlConnection asks the RetryPolicyFactory for a default command retry policy which ends up throwing since RetyPolicyFactory looks for this information in the container.  

The interesting thing is that the ReliableSqlConnection(string, RetryPolicy) constructor actually tries to choose between the default command retry policy (from the container) and if that is null then it will use the passed in connection retry policy as the command retry policy.  So, there seems to be some intent to use the passed in value if the container's value is null.  Of course, the issue is that the container throws if no matching objects can be found in the container.  I'm not sure if this is a bug in the Transient Fault Handling Block or if it is by design.  Either way it would probably be friendlier to use the passed in policy when there is no value in the container similar to if the value was null.

From a design perspective it is hard to answer "why" without someone who was there documenting it or speaking up.  I have no first hand knowledge but the one thing that comes to mind is that a factory using the container to resolve (default) objects is a common pattern used within Enterprise Library.  E.g. ValidationFactory, DatabaseFactory.

Since it sounds like you want to use ReliableSqlConnection without explicitly configuring a container you can use the ReliableSqlConnection(string connectionString, RetryPolicy connectionRetryPolicy, RetryPolicy commandRetryPolicy) constructor to do so.  For example:


var conn1 = new ReliableSqlConnection("abc", policy, policy);
var conn2 = new ReliableSqlConnection("abc", policy, null);

This will get you past creating a ReliableSqlConnection but I haven't tested a complete execution path.

Randy Levy
Enterprise Library support engineer