Can SqlConfigurableRetryProviders be re-used #2260
Replies: 4 comments 2 replies
-
You may find the information at https://devblogs.microsoft.com/azure-sql/configurable-retry-logic-for-microsoft-data-sqlclient/ to have all the answers to your queries. |
Beta Was this translation helpful? Give feedback.
-
If you have a similar retry logic with all the objects, it's safe re-using a provider, which is exposed in SqlConfigurableRetryFactory. The way you should create a new provider and consume it, depends on your application, like concurrent calls and maintenance policy. I'll convert this issue to a discussion. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the info. We have 2
So we have something like: public IDbConnection GetPrimaryConnection()
{
var connection = new SqlConnection(_options.ConnectionString);
connection.RetryLogicProvider = SqlConfigurableRetryFactory.CreateIncrementalRetryProvider(...);
return connection;
}
public IDbConnection GetReadOnlyConnection()
{
var connection = new SqlConnection(_options.ReadOnlyConnectionString);
connection.RetryLogicProvider = SqlConfigurableRetryFactory.CreateIncrementalRetryProvider(...);
return connection;
} Could we have different set of retry policies using the app.config somehow. If not, is there a way to set the retry policy for a connection, but also for all commands executed from that connection when creating that connection ? I would like to avoid having to set the 'default' retry policy for all commands executed on a connection separately. Or isn't that necessary in most cases (and the connection retry should be enough to handle most cases of transient errors). |
Beta Was this translation helpful? Give feedback.
-
I'm adding to this discussion because I had a similar concern and I wasn't able to readily interpret or confirm behavior elsewhere on the web. From what I can tell, we can safely share a single retry logic provider object instance between all connection objects because as a 'provider' class, a SqlConnection object will use this provider object as guidance for creating and tracking a retry counter on the SqlConnection object instead of incrementing a retry counter in the provider object (or maybe it just returns an enumerator object that is never reused). Put another way, we hopefully won't get some sort of crazy problem where all connections fail after only one connection fails because they all share the same retry provider instance. I haven't made the time to comb through all of the code associated with the retry feature, but the best indication I've seen to confirm that a shared provider instance between all SqlConnection instances is safe is that if the SqlConnection.RetryLogicProvider is null (default), the static, default provider (perhaps constructed via XML config) is used and is shared among all connections (an internal SqlConfigurableRetryLogicManager.ConnectionProvider class & property). Let me know, however, if my understanding or interpretation of the documentation is incorrect. |
Beta Was this translation helpful? Give feedback.
-
Is it advised to always create a new retry provider for every connection / command or can they be re-used across many connections / commands. It is unclear from the documentation what the best practices are:
vs creating it for every connection
Same thing goes for commands
Beta Was this translation helpful? Give feedback.
All reactions