Skip to main content

Hi there,

In my current Sitecore project we’ve configured Microsoft SQL Server Always On on the server level to scale any Sitecore SQL Server database. We’ve done this to have High availability disaster recovery (HADR). That’s the first thing you need to enable/setup. Then it comes to configuring the Sitecore solution. To configure SQL Server Always On in our Sitecore solution, we have to edit the SQL Server database connection strings, and then configure the Retryer settings in Sitecore.

So when we were reading through the documentation we ended up with multiple links that talk about these Retryer settings:

When reading through the above documentation, I got me a little bit confused since apparently there are 2 retryers in the dataproviders namespace: Sitecore.Data.DataProviders.Retryer & Sitecore.Data.DataProviders.TransientRetryer. When do you use the Retryer and when the TransientRetryer? In this blog-post I would like to give you a good explanation on the differences.

What’s a transient error?

A transient error, also known as a transient fault, is an error that will resolve itself. Most typically these errors manifest as a connection to the database server being dropped. Also new connections to a server can’t be opened. Transient errors can occur for example when hardware or network failure happens. Another reason could be a new version of a PaaS service that is being rolled out.

On-prem vs Cloud

The first thing we have to check is which setup you’re doing: On-Prem or Cloud (Azure PaaS). In my setup we were doing an On-Prem setup. When dealing with database failovers, the current implementation of the Retryer class does not filter transient errors. The Retryer approach therefore is not a recommended practice when working with Azure SQL. In a cloud environment you’ll find that failed and dropped database connections happen periodically. That’s partly because you’re going through more load balancers compared to the on-premises environment where your web server and database server have a direct physical connection. In order to support transient errors for Azure SQL Databases, the TransientRetryer class was introduced in XP 9.0.

What we can conclude from above is that we have to use TransientRetryer for Cloud setups. That’s a fact, But for On-Prem? Should we say, then you use Retryer? Unfortunately it’s not that simple, cause the TransientRetryer can also be used in on-premises environments as well.

The benefits of using the Retryer for an On-Prem setup lies in the fact that we can configure the ‘Number of tries’ and ‘Interval between tries’ as shown below:

<retryer disabled=”false” type=”Sitecore.Data.DataProviders.Retryer, Sitecore.Kernel”>
<param desc=”Number of tries”>6</param>
<param desc=”Interval between tries”>00:00:00.500</param>
<param desc=”Log each exception (should be used for debug only)”>true</param>
</retryer>

On the other hand, TransientRetryer implements only one built-in strategy by default – Incremental Retry Strategy – retry four times, waiting one second before the first retry, then two seconds before the second retry, then three seconds before the third retry, and four seconds before the fourth retry:

<retryer disabled=”false” type=”Sitecore.Data.DataProviders.TransientRetryer, Sitecore.Kernel”>
<param desc=”Log each exception (should be used for debug only)”>true</param>
</retryer>

Conclusion

TransientRetryer can be recommended if one or more of the following points apply to you:

  • You plan on using cloud environments
  • You don’t need to customize the ‘Number of tries’ and ‘Interval between tries’ setting and are okay with the default built-in strategy
  • You would like to take advantage of other types of strategies developed in the future

Big thanks to Sitecore Support for giving some more clarification on the differences. I hope this blog-posts helps you with choosing the right Retryer when you’re scaling your Sitecore databases whether it’s On-Prem or in the Cloud.

Happy Sitecore-ing!

Robbert