For selfservicing there's no central object which governs the connection so there's no central place to put the strategy.
Instead of your code I'd really use the Execute method on a transient error recovery strategy object, e.g.
var q = from c in metaData.Customer
where c.Country=="USA"
select c;
var strategy = new SqlAzureRecoveryStrategy(); // use defaults
var l = strategy.Execute(()=>q.ToList());
or in your case:
var strategy = new SqlAzureRecoveryStrategy(); // use defaults
strategy.Execute(()=>myEntity.Save(true));
It's a bit cumbersome to cover all bases for selfservicing due to lazy loading and fetch logic in generated code, so we couldn't find a spot where we could easily obtain the set strategy without using locks, as it would require a static location to make all code be able to obtain the set strategy. A strategy has state so that would be problematic.
What you could do is use a unit of work as much as possible and commit that unit of work with a strategy using its Execute method. If you want to use the Save() methods etc. then I'd use a static method which creates a local strategy object and executes a lambda you pass in.
Be aware that a strategy has state, so you can't share it among calls!
e.g.
public static T PerformWithStrategy<T>(Func<T> toPerform)
{
if(toPerform==null)
{
return;
}
return new SqlAzureRecoveryStrategy().Execute(toPerform);
}
where you call it like:
MyHelperMethods.PerformWithStrategy(()=>myEntity.Save(true));
It's not ideal though, but it's a way to get things more centralized and easy to perform within a strategy.