The published advice on transient error handling for Azure SQL recommends
- Delaying "several" seconds before the first retry
- Closing and opening the connection prior to eeach retry
I've poked around in SqlServerRetryingExecutionStrategy and related classes, and can't find any evidence that either of those two recommendations are followed in EF Core - nor have I been able to figure out how I might implement those recommendations in a custom execution strategy.
Additionally, I've found that an Execution Timeout Expired. exception (Error number -2) is explicitly not considered transient -- yet it is the single most frequently occurring exception we encounter in our non-EF database code. The retry strategy we've implemented for that non-EF code closes and re-opens the connection before retrying the query and has completely eliminated failures due to timeout exceptions. I've had to add error number -2 to the errorNumbersToAdd list for EF Core, but, because the connection isn't closed and re-opened, I have zero expectation that retries for those errors will be successful.
Is there a plan to support the recommended transient error handling when targeting Azure SQL?
Is there a way I can implement a custom execution strategy that will close and re-open the database connection?
The published advice on transient error handling for Azure SQL recommends
I've poked around in
SqlServerRetryingExecutionStrategyand related classes, and can't find any evidence that either of those two recommendations are followed in EF Core - nor have I been able to figure out how I might implement those recommendations in a custom execution strategy.Additionally, I've found that an
Execution Timeout Expired.exception (Error number -2) is explicitly not considered transient -- yet it is the single most frequently occurring exception we encounter in our non-EF database code. The retry strategy we've implemented for that non-EF code closes and re-opens the connection before retrying the query and has completely eliminated failures due to timeout exceptions. I've had to add error number -2 to theerrorNumbersToAddlist for EF Core, but, because the connection isn't closed and re-opened, I have zero expectation that retries for those errors will be successful.Is there a plan to support the recommended transient error handling when targeting Azure SQL?
Is there a way I can implement a custom execution strategy that will close and re-open the database connection?