Automatic retries: general purpose
As an application developer I want a general-purpose mechanism that handles the retries of operations that failed because of transient issues.
-
Jason commented
@Shawn, Yes my point was more about 'persistence ignorance' rather than complaining the nature of SQL Azure and the cloud. Don't get me wrong, I'm completely on board with pros and cons of the cloud and how it changes the architecture of our applications. You nailed the concern with your second comment. I want to keep my retry policy concerns low and as close to the database as possible. But, with the current direction of the suggested framework it just seems like one more layer and framework to manage. Some architectures leverage deferred execution with LINQ which means that the retry logic ends up being all over and at the very top of the stack. What they've done here is force you to design your applications their way in order to leverage a couple of loops.
-
Shawn Cicoria commented
Jason - actually, perhaps I'm missing your point. Are you meaning that the SqlConnection client needs to have this retry logic? And the thought of this should be abstraced from the consumer - the LINQ extensions? In that I would agree - but that's not SQL Azure, that the Client communications. For that I agree, MSFT does need to bake that into the layer's closer to the communcation layer to abstract it; but I still want to have some control in driving a policy on "which" interactions have 1 retry vs. 100 retries. Like part of the connection string.
-
Shawn Cicoria commented
The comment on retry logic is a problem with SQL Azure - you're missing the point with the fact that Distributed systems have this inherent risk regardless. We've just been lucky that many solutions to date are right next to the SQL instance on the same LAN segment. In fact errors could occur they were just so infrequent we just didn't concern ourselves with it.
In distributed systems you design for failure, and that design gives us greater service reliability. We don't buy enourmous guaranteed pipes to work around potential loss of communication and other issues.
When SQL Azure becomes a service in a distributed architecture then it to is subject to the unreliability of a network link - and no fault of SQL Azure. There could be 30 hops between Consumer and SQL Azure.
-
Jason commented
The technique/framework provided by the Azure CAT team is a bad approach when using the Entity Framework. The pattern is to basically wrap all your queries with an Action that loops and retries. The problem is this doesn't play well with the many patterns and ways people use LINQ datalayers in their applications. 'Retry Policies' are not a concern for any of application layers since it is a problem with SQL Azure itself. The responsibility should be with the code that makes the connection which means it should be a responsibility for the Entity Framework itself.
-
Andy Milligan commented
The Transient Fault Handling Framework from the Microsoft AppFabric CAT team has already delivered a strong approach for doing this:
http://appfabriccat.com/2011/02/transient-fault-handling-framework/We rely upon this extensively at our startup (http://allmyplans.com) and we were able to remove a lot of cumbersome, repetitive error handling code.