This post has been moved to a new location. Please follow the link below. Thank you.
Is there a best-practices example as it relates to EF 4.0 Code-First approaches relying on DbContext rather than native EF?
I guess one question I have is whether it's appropriate to forcibly open the connection before SaveChanges is called, which under EF/CF would normally open the connection and execute the transactionally wrapped commands at the very last moment. Does it matter?
Also, is there a best practices way to grab (and wrap) the connection object from a DbContext when using this approach?
We are collaborating with the Entity Framework team to be able to provide a consistent story here. We will publish our recommendations in due course.
Great code! thanks. I get the ado.net sample to work, but when i look at your AdventureWorksEntities.cs in the test project, I can't see how the retry logic gets executed when you call things like datacontext.savechanges() (and in my testing, it does not). Could you show (or tell) where the extension method gets called that will execute the retry logic? I don't get it from the test project or the article.
Peter, thank you for reaching out to us.
Please note that the test project included into the source code distributed on the MSDN Code Gallery is reserved for internal testing and prototyping purposes and should not ideally be used as implementation guidance. I recommend you to review the following post that specifically talks about retry scenarios with Entity Framework.
As shown previously it isn’t hard to run Workflow Services on Windows Azure. In fact all we need to do
There is a dependency on Microsoft.ServiceBus but I don't have that dll in my system, that I know of. It does not show in the references dialog and is not in the Windows Azure 1.3 SDK folders. I searched Microsoft Download and it returned nothing. Where can I get this dll? Or where on my system might I find it?
Never mind, I found it. It is part of the AppFabric SDK which I did not have installed. In case anyone is looking for it I got it from:
When will MS Patterns & Practices Data Access Block include this type of logic and config?
It's a perfectly valid question for the P&P team. We already provided them with all the code artifacts and asked to integrate the retry framework into the DAB. If you look at the work we have done with the EntLib's DAB, you will see that it's not too difficult to implement such integration yourself.
Niall, perfect timing!
The EntLib team is currently in the exploration phase for the Windows Azure Integration Pack for Enterprise Library 5.0. Please suggest this as a story on our uservoice site. Other users will be able to vote on this and we'll take that into consideration when finalizing our product backlog.
Enterprise Library producer
Here's the uservoice link: entlib.uservoice.com/.../101257-azure-integration-pack
Thank you so much for making this library! However I cannot get it to work with SQL Server Express because the connection strings contain (Server=hostname\SQLEXPRESS), and GetDnsSafeConnectionString() tries to look the whole thing up in the DNS. I can work around this by conditionally only calling OpenWithRetry() when I know it is an SQL Azure database, but is there a better way?
Thank you for getting in touch. SQL Server Express is fully supported by our framework. DNS lookups performed by GetDnsSafeConnectionString should not impact your use of SQL Express, although we may be performing DNS lookups against the full instance name which is not ideal. I have modified this behavior so that we handle SQL Express instance names more efficiently. The update has already been put on our MSDN Code Gallery. Please review and let us know if there will any further questions.
Wow, that was fast! Working perfectly for me now.
I tried this RetryPolicy because I want a robust application.
I have the following code:
int MaxRetry = 5;
int DelayMS = 100;
policy = new RetryPolicy<SqlAzureTransientErrorDetectionStrategy>(MaxRetry, TimeSpan.FromMilliseconds(DelayMS));
Type = policy.ExecuteAction<string>(() => context.properties.First(p => p.Name == "not_exist_type_id").Value);
but it sometiomes throws exception:
"Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding."
The RetryPolicy is not working if the connection times out?